Generational GC and the Scavenger

The generational hypothesis

The browser/03-v8-internals/05-gc-orinoco lesson gives the overview; here we open the Scavenger’s mechanics.

The empirical foundation of every production GC is the generational hypothesis: most objects die young. The lifetime distribution of allocations is wildly bimodal — a huge majority are transient (request temporaries, intermediate strings, per-render React elements) and become unreachable within a few milliseconds, while a small minority (caches, the module graph, connection pools) live for the whole process. Almost nothing dies in the middle.

V8 exploits this by splitting the heap by age:

• New space (young generation) — where every ordinary object is born. Small: a budget that grows on demand up to roughly 1–8 MB per isolate (tunable via --max-semi-space-size). Collected frequently and cheaply by a minor GC.
• Old space (old generation) — long-lived survivors. Can be hundreds of MB to gigabytes (--max-old-space-size). Collected infrequently by a major GC (next lesson).

Because new space is small and almost everything in it is dead by collection time, a minor GC touches very little live data — that is the entire payoff.

New space is two semi-spaces; allocation is a bump pointer

New space is physically two equal halves called semi-spaces: to-space (active) and from-space (idle). Allocation into to-space is the cheapest operation in the engine — a bump-pointer allocator: keep a pointer to the next free byte, hand it out, advance the pointer by the object size. No free-list search, no fragmentation, just an add and a bounds check.

// Conceptually, every `new`/object literal does:
//   if (top + size > limit) triggerScavenge();
//   addr = top;
//   top += size;          // bump
//   return addr;
const point = { x: 1, y: 2 };   // a bump-pointer allocation in to-space

When the bump pointer hits the limit (to-space is full), a Scavenge (minor GC) fires.

The Scavenger: Cheney’s copying algorithm

The Scavenger is a copying collector running Cheney’s algorithm. The key inversion versus mark-sweep: it does not look at dead objects at all. It copies out the live ones and abandons the rest wholesale.

1. Flip. The roles swap: the current to-space becomes from-space, the empty half becomes the new to-space.
2. Evacuate roots. Scan the roots (stack, globals, handles) plus the remembered set of old→new pointers (see lesson 04 — old space may reference young objects, and we are not scanning old space). Copy each referenced live young object from from-space into to-space, leaving a forwarding pointer in the old slot.
3. Cheney scan. Walk the newly copied objects in to-space breadth-first as a work queue; for each, copy any from-space objects it references (or follow an existing forwarding pointer if already copied), updating the pointer to the new location. This continues until the scan pointer catches the allocation pointer — the queue is empty.
4. Reclaim implicitly. Whatever was not copied is simply left in from-space, which is now declared empty in one stroke. Dead objects cost nothing to reclaim — they are never visited.

The work is proportional to the live set, not the allocated set. With the generational hypothesis holding, the live set is tiny, so the Scavenge is fast.

Promotion: surviving makes you old

An object that survives a Scavenge is not yet trusted to be long-lived; it is copied into to-space and given another chance. If it survives a second Scavenge, V8 concludes it is probably long-lived and promotes it: copies it into old space instead of back into a semi-space. (V8 also promotes early under “intermediate” generation pressure, and directly allocates very large objects into old/large-object space, but “survive twice → promote” is the model to hold.)

Promotion is why a Scavenge can leave new space nearly empty: transient objects were never copied (dead), and the few real survivors graduated to old space. New space stays small and the next Scavenge stays cheap.

Orinoco: making it parallel

Orinoco is the umbrella name for V8’s modern GC project — the set of techniques that turn a stop-the-world collector into a mostly-concurrent, parallel, incremental one. For the Scavenger specifically, Orinoco made it parallel: multiple helper threads share the copying work via dynamic work-stealing, so wall-clock pause time drops even though there is more raw work. Because new space is small, minor pauses land in the sub-millisecond to low-millisecond range — short enough to fit comfortably inside a 16.6 ms animation frame. The heavier concurrency and incrementality apply mostly to the major GC, which is the next two lessons.