Write barriers: the price of incremental and generational GC

Why a store is not free

The previous two lessons left two correctness debts, both created by the same thing — a pointer mutated between or during collections:

1. Generational debt. A minor GC scans only young space (plus roots), because scanning gigabytes of old space on every Scavenge would destroy the whole point of generational GC. But old objects can hold references to young objects (oldArray.push(youngObj)). If V8 ignored those, it would free a young object that old space still references.
2. Marking debt. Concurrent/incremental marking lets JS mutate the graph mid-trace. A store can make a black (scanned) object point to a white (unreached) object, violating the tri-color invariant, so the marker finishes without visiting a live object and the sweep collects it.

A write barrier is a small piece of code the compiler emits around (nearly) every store of a pointer into a heap object. It runs at obj.field = ptr time and does whatever bookkeeping is needed to keep both questions answered. One barrier, two jobs.

Job 1: the generational barrier and the remembered set

To avoid scanning old space on a minor GC, V8 maintains a remembered set (implemented via a store buffer that is later processed into per-page slot sets): a record of every slot in old space that holds a pointer into young space. When you write oldObj.field = youngObj, the generational write barrier notices the store crosses old→young and records that slot.

At the next Scavenge, V8 treats the remembered set as extra roots: it scans those recorded slots to find young objects kept alive by old-space references, without walking old space at all. After the Scavenge updates the moved young objects’ addresses, the remembered set is what lets the old-space pointers be fixed up.

const cache = [];          // promoted to old space over time
function handle(req) {
  const entry = { req };   // young
  cache.push(entry);       // OLD array now references YOUNG entry
  //                          ^ generational write barrier records this slot
}

The barrier only fires for the old→young direction. Young→young and young→old stores are uninteresting to a minor GC (young is fully scanned anyway; old→? is the major GC’s problem), so V8 elides the barrier in those cases.

Job 2: the incremental/marking barrier (Dijkstra-style)

During concurrent marking, the same store hook protects the tri-color invariant. V8 uses a Dijkstra-style insertion barrier: when the mutator stores a pointer to a white object into any object during marking, the barrier greys the white target (pushes it onto the marking worklist). This guarantees the marker will eventually scan it, so it cannot be left white and wrongly collected. (The classic alternative is a Yuasa snapshot-at-the-beginning barrier, which greys the overwritten old referent instead; V8’s design uses Dijkstra-style insertion for its concurrent marker. Either way the goal is identical: no live object escapes the trace.)

Because both jobs trigger on the same event — a pointer store into a heap slot — V8 fuses them into a single barrier path that checks the relevant conditions (is marking active? does this store cross old→young?) and does the minimum work.

Why Smi stores skip the barrier

The barrier exists only to track pointers between heap objects. A Smi (small integer — a 31-bit integer on 64-bit V8) is not a pointer: it is encoded directly inside the tagged value, with its low tag bit zero, so it cannot reference a heap object at all. Storing a Smi into a field — obj.count = 42 — creates no inter-object reference, so V8 emits no write barrier for it. The same is true for storing other immediates. This is one more reason the Smi/HeapNumber distinction from unit 02 matters for performance: integer-heavy field writes are barrier-free, while writes that store object or boxed-double pointers pay the barrier check.

The cost, and where it bites

Each barrier is cheap individually — a few instructions: load the target’s page metadata or check a marking flag, branch, and in the slow case push to a worklist or store buffer. Call it a handful of cycles per pointer store. That is invisible in ordinary code. It becomes measurable in allocation- and mutation-heavy hot paths: tight loops that build large object graphs, repeatedly repoint fields, or push millions of object references into long-lived containers. There, barrier overhead is real, and it is one of the hidden costs of “just push objects into an array” versus working with typed arrays or Smi-encoded data.