68. V8’s garbage collector

Watching it work

Here is a loop that makes three million small objects and keeps one in ten:

const keep = [];
for (let i = 0; i < 3e6; i++) {
  const p = { x: i, y: i };
  if (i % 10 === 0) keep.push(p);
}
console.log(keep.length);

--trace-gc prints a line for every collection. Real output, Node v22.23.4 (V8 12.4), with the process prefix removed and the lines cut short:

$ node --trace-gc gc.js
22 ms: Scavenge 4.4 (5.1) -> 3.5 (6.1) MB,…
24 ms: Scavenge 4.4 (6.1) -> 3.6 (6.4) MB,…
…
58 ms: Scavenge 19.1 (28.0) -> 12.6 (28.7)…
67 ms: Mark-Compact 13.4 (28.7) -> 10.2 …
  … finalize incremental marking via
  stack guard; GC in old space requested
70 ms: Scavenge 18.0 (27.2) -> 10.9 (27.2)…
…
300000

The numbers either side of -> are heap sizes in MB before and after. There were 25 scavenges and one Mark-Compact. Two collectors, then: chapter 60 sketched why. Here is how V8 does it.

Two generations

V8’s heap has a young generation, split into a nursery and an intermediate part, and an old generation. Objects start in the nursery. One that survives a collection becomes intermediate, and one that survives another moves to the old generation^[1]. Most objects never get that far: the generational hypothesis says most objects die young^[1]. In the loop above, nine in ten ps are garbage by the next iteration.

The Scavenger

The young generation is collected by the Scavenger, which collects nothing else. It uses two halves, called semispaces: objects are allocated in one, from-space, while the other, to-space, stays empty. A scavenge copies every live object from one to the other, then the two swap roles^[1]. Step through it:

Copying finds, moves and fixes pointers in one go. Each moved object leaves a forwarding address behind, so other pointers to it can be updated^[1]. V8 used exactly this algorithm, Cheney’s, until version 6.2. A post from late 2017 describes its replacement: a parallel Scavenger, with several threads copying at once and stealing work from each other^[2]. Node 22 still has it on: node --v8-options lists --parallel-scavenge as the default and describes the new space as “two semi-spaces”.

Mark-Compact

The old generation is big and its objects tend to live, so copying all of it would be wasteful. Instead, the major collector, Mark-Compact, collects the whole heap in three steps. It marks everything reachable from the roots, as your Drip collector does. It sweeps: the gaps left by dead objects go onto free-lists, sorted by size, for future allocations. And it compacts only some pages, chosen by a fragmentation heuristic, copying their survivors elsewhere. The rest are only swept, because copying lots of long-lived objects is expensive^[1].

Marking a big heap all at once could stop the program for a long time. So V8 marks in the background: concurrent marking starts as the heap approaches a limit, helper threads mark while JavaScript runs, and the main thread pauses only for a short finishing step, then compacts in parallel^[1]. The trace above shows that finishing step: “finalize incremental marking”.

The write barrier, twice over

Both collectors depend on the same small piece of code, run on every pointer store into an object.

First, the scavenge. It skips the old generation, so it would miss a young object held only by an old one. The write barrier records each old-to-new pointer, and those records become roots^[1]. In the parallel Scavenger, these remembered sets are kept per page, and they are usually most of the roots^[2].

Second, marking. If JavaScript runs while the marker works, it could store a pointer to an unmarked object into one the marker has finished with, hiding a live object. V8’s barrier for concurrent marking does this after each object.field = value^[3]:

if (color(value) == white &&
    atomic_color_transition(
        value, white, grey)) {
  marking_worklist.push(value);
}

Barriers cost time on every store, so compilers avoid them when they can. Maglev skips the barrier entirely when storing into an object it has just allocated, as long as no other allocation happened in between^[4].

Your turn

function scavenge(from, roots) {
  const to = [];
  const fwd = []; // old index -> new
  return { to, roots };
}

function write(owner, key, val, rs) {
  owner.fields[key] = val;
}
function youngRoots(stack, rs) {
  return stack;
}

What you learned

• V8’s heap has a young generation (nursery and intermediate) and an old generation. Most objects die young.
• The Scavenger copies survivors between two semispaces, leaving forwarding addresses, and promotes objects that survive twice. Its cost depends on what survives.
• Mark-Compact marks the whole heap (mostly concurrently), sweeps into free-lists, and compacts only fragmented pages.
• The write barrier records old-to-new pointers for the Scavenger and keeps concurrent marking correct.
• --trace-gc shows both collectors: many Scavenges, the occasional Mark-Compact.