Incremental, Concurrent, and Parallel GC

The Stop-the-World Problem

Here's the nightmare: your user is scrolling through a feed, animations are running at 60fps (16.6ms per frame), and the garbage collector decides it needs to mark every live object in a 200MB heap. If the GC stops JavaScript execution while it works, that pause might take 50-200ms — visible jank, dropped frames, and a user who thinks your app is broken.

This is stop-the-world (STW) collection: pause all JavaScript execution, run the GC to completion, then resume. Early garbage collectors worked this way. It's simple and correct, but the pause times are unacceptable for interactive applications.

V8 uses three strategies to minimize STW pauses: incremental marking, concurrent marking, and parallel collection. Together, they keep major GC pauses under a few milliseconds in most cases.

Tri-Color Marking: The Foundation

Before understanding incremental and concurrent GC, you need tri-color marking — the abstraction that makes interruptible marking possible.

Every object is in one of three states during a GC cycle:

The marking algorithm:

1. Start: All objects are white. Root objects are colored gray and added to the worklist.
2. Process: Pick a gray object from the worklist. Scan its references. Any white object it references becomes gray (added to worklist). Once all references are scanned, the gray object becomes black.
3. Done: When the worklist is empty (no more gray objects), every black object is alive. Every white object is garbage.

The key property of tri-color marking: the invariant. At no point can a black object directly reference a white object. If it could, we'd miss scanning that white object (black objects are never revisited), and we'd incorrectly collect it. Gray objects act as the barrier between black and white.

Incremental Marking

Instead of marking the entire heap in one STW pause, V8 breaks marking into small chunks interleaved with JavaScript execution:

[JS code] → [mark 1ms] → [JS code] → [mark 1ms] → [JS code] → [mark 1ms] → [sweep]

Each marking step processes some gray objects from the worklist, then yields back to JavaScript. The tri-color state persists between steps — V8 remembers which objects are white, gray, and black.

The Problem: Mutator Interference

While JavaScript runs between marking steps, it can modify the object graph. This is dangerous:

// Between marking steps, JS runs:
const black_obj = alreadyMarkedObject;  // GC already colored this black
const white_obj = newlyCreatedObject;   // GC hasn't seen this yet (white)

black_obj.ref = white_obj;  // Black now references white — invariant violated!

If the GC doesn't know about this change, it will never visit white_obj (because black_obj is already black and won't be re-scanned). white_obj would be incorrectly collected.

Write Barriers to the Rescue

V8 inserts write barriers — tiny code snippets that execute every time a pointer field is written. When a write creates a reference from a black (or any marked) object to a white object, the barrier re-colors the target gray (or marks the source for re-scanning):

// Pseudo-code for a write barrier
function writeBarrier(object, field, newValue) {
  object[field] = newValue;  // the actual write

  if (gcIsMarking && isBlack(object) && isWhite(newValue)) {
    markGray(newValue);  // add to worklist for scanning
  }
}

Concurrent Marking

Incremental marking breaks the pause into smaller pieces, but the total marking work is still done on the main thread (just in chunks). Concurrent marking moves most of the marking work to a background thread that runs simultaneously with JavaScript:

Main thread:   [==== JS code running ============================]
                                                                [short pause: finalize]
Background:    [============== marking objects ==================]

The background thread traverses the object graph and marks reachable objects. Meanwhile, JavaScript continues executing on the main thread. When the background thread finishes, a short STW pause finalizes: re-scan objects modified during concurrent marking (tracked by write barriers), handle edge cases, and begin sweeping.

Challenges of Concurrent Marking

The background thread reads the object graph while the main thread modifies it. This is a classic concurrent data structure problem:

1. New references: Main thread creates A→B after background already marked A as black. Write barrier handles this.
2. Deleted references: Main thread removes the only reference to an object the background hasn't reached yet. Safe — the object was already unreachable; collecting it is correct.
3. New objects: Objects allocated during concurrent marking. V8 allocates them as black (already marked alive) to avoid the background thread needing to discover them.
4. Object movement: The Scavenger might move Young Generation objects during concurrent marking. V8 coordinates this carefully with forwarding pointers.

Parallel Scavenging

The Young Generation's Scavenger can also be parallelized. Instead of one thread copying survivors from From-space to To-space, multiple threads divide the work:

1. Main thread and helper threads each take a portion of the root set
2. Each thread traces from its roots, copying live objects to To-space
3. Threads use atomic operations to claim regions of To-space and avoid conflicts
4. Forwarding pointers (stored in From-space) ensure objects aren't copied twice

Parallel scavenging typically reduces minor GC pause times by 30-50% compared to single-threaded scavenging.

V8's Orinoco GC: The Complete Picture

V8's garbage collector is called Orinoco. Here's how all the pieces fit together:

Minor GC (Young Generation)

1. Parallel Scavenger runs on multiple threads
2. Semi-space copying: live objects move From-space → To-space (or promote to Old Space)
3. Typical pause: 1-3ms

Major GC (Old Generation)

1. Concurrent marking starts on a background thread while JS runs
2. Incremental marking steps happen on the main thread when the background thread needs help or during idle time
3. Short STW pause to finalize marking (re-scan write barrier records)
4. Concurrent sweeping frees memory on background threads while JS runs
5. Parallel compaction (if needed) runs on multiple threads during a pause
6. Typical finalization pause: 2-5ms (down from 50-200ms without these techniques)

Measuring GC Impact

You can observe GC activity in several ways:

Chrome DevTools Performance Panel

Record a trace and look for:

• Minor GC entries (Young Generation collections)
• Major GC entries (Old Generation collections)
• Yellow sections in the flame chart labeled "GC"
• Total GC time as a percentage of the recording

V8 Flags (Node.js)

# Print GC events with timing
node --trace-gc your-script.js

# Output:
# [12345:0x...] 42 ms: Scavenge 2.1 (4.0) -> 1.8 (4.0) MB, 1.2 / 0.0 ms
# [12345:0x...] 1337 ms: Mark-sweep 8.2 (16.0) -> 6.1 (16.0) MB, 3.5 / 0.0 ms

# More verbose GC statistics
node --trace-gc --trace-gc-verbose your-script.js

The format: [pid] time: Algorithm before (capacity) -> after (capacity), pause / concurrent