V8 Garbage Collection Mechanisms: Orinoco and Beyond

The Generational Hypothesis

Modern memory management inside the V8 JavaScript engine is predicated on a crucial empirical observation: most allocated objects die incredibly young. Temporal variables used in loops or immediate DOM calculations become obsolete almost instantly. Conversely, objects that survive the initial allocation phase tend to live for the entire lifecycle of the application context.

The Scavenger and the Old Space

V8 divides its memory heap primarily into the 'New Space' (nursery) and the 'Old Space'. Memory allocations begin in the New Space. A rapid, lightweight algorithm called the 'Scavenger' regularly sweeps this tiny area, completely discarding unreferenced objects. It operates using a Cheney algorithm, copying only the surviving objects between semi-spaces. If an object survives two scavenger cycles, V8 formally evicts it and promotes it to the Old Space.

Mark-Sweep and Concurrent Tracing

The Old Space requires a far heavier 'Mark-and-Sweep' or 'Mark-and-Compact' paradigm. Historically, analyzing thousands of long-lived objects forced V8 to drastically pause the main thread—creating visually stuttering 'Stop-The-World' jank in web pages. Modern V8 iterations (project Orinoco) have heavily parallelized this garbage collection. Using concurrent marking, background worker threads trace obsolete memory while the main JavaScript thread continues execution undisturbed, achieving sub-millisecond GC latency.

Detailed Minor GC (Scavenger) Mechanics

V8's New Space (also called the Young Generation) is divided into two equal-sized semi-spaces: the "from-space" and the "to-space." Memory allocation always happens in the from-space using a simple bump pointer—the fastest possible allocation strategy, requiring only an increment of a pointer variable. When the from-space fills up (typically at 1-4MB), the Scavenger GC kicks in and evacuates live objects to the to-space, compacting them contiguously to eliminate fragmentation. The from-space is then cleared entirely, and the two spaces swap roles.

The Scavenger identifies live objects by starting from GC roots (the call stack, global handles, and V8's internal handle scope) and tracing all reachable object references. Objects that have survived one Scavenger cycle are marked as "intermediate." Objects that survive a second cycle are promoted to the Old Space, under the assumption that they will remain alive for a long time. This two-cycle promotion threshold balances the cost of premature promotion (wasting Old Space capacity on short-lived objects) against the cost of repeated Scavenger cycles on objects that will ultimately be long-lived.

Write Barriers and Remembered Sets

A critical challenge in generational GC is tracking references from Old Space objects to New Space objects. Without this tracking, the Scavenger would need to scan the entire Old Space to find all roots pointing into the Young Generation—defeating the purpose of generational collection. V8 solves this with a "write barrier": every time application code creates a pointer from an old object to a young object, the write barrier intercepts the operation and records the reference in a "remembered set." During Scavenge, only remembered set entries (plus stack roots) need to be traced, keeping the Young Generation collection time proportional to the number of live young objects rather than the total heap size.

Concurrent and Incremental Major GC

V8's major GC for the Old Space has evolved through several generations of optimization. The original "stop-the-world" mark-sweep algorithm would pause JavaScript execution for 10-100+ milliseconds on large heaps—creating visible jank in web applications. Modern V8 (Orinoco project) addresses this through three key innovations: incremental marking breaks the marking phase into small chunks interleaved with JavaScript execution, concurrent marking runs marking on background threads while the main thread continues executing JavaScript, and concurrent sweeping reclaims dead memory on background threads without any main thread involvement.

The result is that major GC pauses in modern V8 are typically under 2 milliseconds, even on heaps exceeding 1GB. For web developers, this means that garbage collection is rarely the cause of animation jank or input latency in modern browsers. However, understanding GC behavior remains important for performance-critical applications: excessive object allocation rates can still overwhelm the Scavenger, and creating large numbers of long-lived closures or event listener references can cause memory leaks that gradually degrade Old Space performance over the application's lifetime.