Orinoco GC: parallel scavenger, concurrent marking, and write barriers

A Node.js service runs fine for a week, then every 60 seconds there is a 5ms pause that shows up in p99 latency. The application code changed nothing. The GC cycle crossed an old-generation threshold. Understanding Orinoco is the difference between guessing and diagnosing.

The heap layout

The V8 heap is divided into two generations:

• Young generation — newly allocated objects, typically 1–8 MB. Collected frequently (minor GC).
• Old generation — long-lived objects, can be hundreds of MB. Collected infrequently (major GC).

Objects start in young gen. Those that survive two minor GCs are promoted to old gen. This generational design exploits the observation that most objects die young — minor GC can be fast because the live set is small.

Minor GC: the parallel Scavenger

The scavenger uses a copying collector with two semispaces:

1. From-space holds live objects; to-space is empty.
2. On collection, V8 walks roots (stack, globals, registers), copies reachable young objects to to-space, updates pointers.
3. Dead objects are abandoned in from-space.
4. Survivors of two minor GCs are promoted to old generation.

The scavenger has been parallel since Orinoco’s first phase (V8 6.2, 2017): multiple worker threads share the work via dynamic work-stealing. Main-thread pauses are ~1ms because the young-gen live set is small and parallelism keeps wall-clock time low.

Major GC: Mark-Compact with concurrent marking

Old-generation collection traces all live objects, sweeps dead ones, and compacts survivors to reduce fragmentation. Pre-Orinoco this was a stop-the-world operation lasting hundreds of ms on large heaps.

Orinoco’s key innovation: concurrent marking — a background thread walks the heap while JavaScript executes on the main thread. The main thread pays a brief final-marking pause (single-digit ms) plus the sweep/compact phase (parallel across worker threads but still blocking). Result: main-thread pause reduced ~50% on WebGL-heavy workloads.

Write barriers

For concurrent marking to be correct while JS simultaneously mutates the heap, V8 uses write barriers: small code emitted at every property write that may cross from a black (already-marked) object to a white (not-yet-visited) object.

V8 uses snapshot-at-the-beginning (Yuasa) semantics: when the main thread overwrites a reference to a white object, the barrier shades the original (overwritten) referent grey so the marker will still visit it. This preserves the invariant “every object reachable at marking start will be visited”, even as the main thread races ahead. The write barrier costs ~3–5 cycles per write; V8 invests heavily in keeping it cheap.

Modern V8 uses tri-color marking (white/grey/black) with snapshot-at-the-beginning semantics and hybrid concurrent + incremental scheduling. Incremental marking amortises GC work across JS execution with no observable single pause.