Garbage collection · Memory management
GC Visualizer
Allocate objects, mutate references, run mark-and-sweep. Watch the reachable set glow green and the rest get reclaimed.
Every modern language manages heap memory for you — but only by running an algorithm under the hood. This is that algorithm, slowed down. Build a small object graph from roots, then run GC and watch the mark phase BFS outward from the roots, painting everything reachable. The sweep phase reclaims the rest. Toggle to reference counting and build a cycle to see why most modern runtimes still ship a tracing collector alongside any RC scheme.
What’s happening under the hood
- ›Memory bugs (use-after-free, double-free, leaks) were the dominant security-bug class for decades — Microsoft and Google have each reported that ~70% of their critical vulnerabilities trace back to manual memory errors. GC trades a small runtime cost for an entire class of bugs disappearing.
- ›The reachability invariant: an object is live iff it can be reached from a root by following references. Roots are the stack frames + global registers + CPU registers a real runtime walks at GC time. Everything else is, by definition, garbage.
- ›Three regimes: manual (C, C++, Zig) — fastest, most error-prone; reference counting (Swift, CPython) — incremental, cheap, but cycles leak without a cycle-detector; tracing (Java, JavaScript, Go, .NET) — periodic stop-the-world or concurrent walks, handles cycles natively, costs throughput and tail latency. There is no free lunch — every language picks its trade-off.
Dig deeper
Phase 7 · Advanced SystemsThe concept you just explored is taught with full depth in the formal DURA curriculum.