What is Garbage Collection and How Does It Work?

Garbage Collection (GC) is automatic memory reclamation that frees objects no longer reachable from any root reference. Roots include active stack frames, static variables, thread local storage, and native handles. If an object cannot be traced from these roots, it's dead and eligible for reclamation.

Most production collectors follow a mark sweep compact pattern. The mark phase traverses the object graph starting from roots, identifying all live objects. The sweep phase reclaims memory from unreachable objects. The compact phase optionally moves survivors together to eliminate fragmentation and enable fast bump pointer allocation (simply incrementing a pointer for new objects, rather than searching free lists).

Modern collectors maintain a tri color invariant during concurrent operation: white objects are candidates for collection, gray objects are reachable but not yet scanned, and black objects are reachable with all references scanned. Write barriers (small code snippets on pointer updates) and read barriers ensure the mutator (your application code) can safely run alongside GC phases without missing references or incorrectly freeing live objects.

The key insight is that GC trades developer productivity and safety for runtime overhead and unpredictable pauses. You gain freedom from manual memory management bugs like use after free and memory leaks, but accept CPU cost for tracing (typically 5 to 20 percent overhead) and periodic pauses for evacuation or compaction.

💡 Key Takeaways

•Reachability is the fundamental principle: objects unreachable from roots (stacks, statics, thread locals, native handles) are dead and can be reclaimed

•Mark sweep compact is the dominant pattern: mark finds live objects via graph traversal, sweep frees dead ones, compact moves survivors to eliminate fragmentation

•Tri color invariant enables concurrency: white (unprocessed), gray (reachable but unscanned), black (fully scanned) sets with write/read barriers allow mutator to run alongside GC

•Bump pointer allocation is a key benefit of compaction: after moving objects together, allocation becomes a simple pointer increment rather than searching free lists, reducing allocation overhead to nanoseconds

•GC trades developer productivity for runtime cost: eliminates manual memory bugs but adds 5 to 20 percent CPU overhead and introduces unpredictable pause times

📌 Examples

Stack frame holds reference to User object, User references Order list, each Order references Product: all reachable and live. Temporary String built during request processing has no remaining references after response sent: unreachable and eligible for collection

V8 JavaScript engine in Chrome uses tri color marking with write barriers so web page scripts can continue executing while GC marks objects in background, then briefly pauses to finalize and evacuate survivors

Java Virtual Machine (JVM) uses card tables (byte arrays marking 512 byte regions) as write barriers: when mutator updates a pointer, corresponding card is marked dirty so young generation GC knows which old objects to scan without traversing entire old heap

← Back to Garbage Collection Fundamentals Overview