GC internals: tri-color invariant, write barriers, and per-runtime deep-dives

A JVM service migrates from G1 to ZGC. Pauses drop from 60 ms to sub-millisecond on a 16 GB heap — but throughput drops 12% and memory use climbs 18%. Understanding why requires knowing what colored pointers are and what load barriers cost.

Tri-color marking and the write barrier

Tri-color abstraction (Dijkstra 1978) is the formal foundation of concurrent GC. Objects are classified into three colors:

• White — not yet visited; candidate for collection if marking ends while still white.
• Grey — visited, but children not yet fully scanned.
• Black — visited, all children scanned; considered live.

Marking moves grey objects to black by scanning their children and greying each unvisited child. When no grey objects remain, all white objects are unreachable and may be reclaimed.

The fundamental invariant: a black object must never directly reference a white object. If a mutator thread writes a reference from a black object into a white object’s field after the black was scanned, that white object becomes unreachable in the GC’s view but reachable in the program’s. The collector would reclaim live memory — silent heap corruption.

SATB vs incremental-update barriers

The write barrier prevents invariant violations by intercepting every reference write:

Snapshot-at-the-beginning (SATB): the barrier marks the old reference about to be overwritten, ensuring it survives this cycle. The collector behaves as if it snapshotted the heap at GC start. Used by G1, Shenandoah, ZGC, and Go’s hybrid Yuasa-style barrier.

Incremental-update (Dijkstra-style): the barrier marks the new reference being written into a black object, ensuring the newly pointed-to object is scanned before the cycle ends. Used by CMS and classic V8 mark-compact.

SATB is more conservative — it may preserve objects that became garbage during the cycle (floating garbage, reclaimed in the next cycle). But it gives stronger guarantees about marking termination and is simpler to reason about. Incremental-update may require a re-marking phase to fix up changes missed during concurrent marking.

Both cost 2–10% CPU on every reference write — the price of concurrent marking without stop-the-world pauses.

Go’s pacer redesign

Go 1.18’s GC pacer rewrite (proposal 44167, by Michael Knyszek) replaced heuristics with a closed-loop control system. The old pacer estimated when to start the next GC cycle so it would finish just before the heap doubled; it had instability at high allocation rates and made poor decisions on cgo-heavy workloads.

The new pacer uses a PI controller (proportional-integral) on two signals: heap-growth rate and GC CPU utilisation. The controller targets GC finishing just before the heap reaches the goal (GOGC-derived), with integral feedback preventing sustained drift.

GOMEMLIMIT (added Go 1.19) integrates into the pacer: as the process approaches the limit, the pacer pulls GC forward — accepting higher GC CPU — to prevent OOM. When the limit is respected, the pacer backs off.

Senior production advice: set GOMEMLIMIT to ~90% of the container’s memory limit; leave GOGC at the default 100 unless profiling shows a specific reason to change it. GOGC=off is only safe for memory-bounded batch jobs that deallocate via process exit.

The redesign reduced pause variance by ~50% on real workloads. Reading: Knyszek’s GopherCon 2022 talk on the pacer redesign.

ZGC and colored pointers

ZGC (JEP 333, JDK 11 experimental; production in JDK 15 via JEP 377) achieves sub-millisecond pauses on heaps up to 16 TB using two innovations:

Colored pointers pack metadata bits into the 64-bit pointer itself. ZGC uses bits 0–41 for the address (capping the heap at ~4 TB), and bits 42–45 for marking state — “good” colors vs “bad” colors indicating relocation or pending work.

Load barriers intercept every heap load (every pointer dereference). If the color is “bad,” the barrier triggers a slow path to update the pointer in-place. Because the barrier runs inline on every load, the application participates in GC’s work incrementally instead of waiting for a big stop-the-world phase.

The result: marking, relocation, and reference processing all happen concurrently. STW phases are limited to root scanning — sub-millisecond even on multi-TB heaps.

The tradeoff: load barriers cost ~5–15% CPU on read-heavy workloads. ZGC also requires multi-mapped heaps for fast relocation, inflating virtual memory significantly (though not physical RSS). The 12% throughput drop and 18% memory increase in the hook scenario are expected ZGC costs — not bugs.

Generational ZGC (JEP 439, JDK 21+) adds a young generation, closing most of the throughput gap with G1. Production teams on JDK 21+ should evaluate generational ZGC when migrating.

V8 Orinoco

V8’s Orinoco project (2017+) moved V8’s GC from mostly stop-the-world to mostly concurrent. Key pieces:

• Concurrent marking: marking runs on a background thread alongside JavaScript execution. Write barriers (SATB-style) maintain consistency with the mutator.
• Parallel compaction: multiple threads move objects in parallel during the STW compaction phase, reducing its duration.
• Young-gen scavenger parallelism: multiple threads evacuate the young heap in parallel.

Result: typical web workloads see pauses ≤10 ms, with most marking work hidden in the background. Memory overhead: ~5–15% for marking infrastructure (write barriers, marking worklist).

Node.js inherits Orinoco by default. Tuning is via --max-old-space-size (old heap cap) and --max-semi-space-size (young heap, affects minor GC frequency). Major Orinoco changes can shift performance characteristics across Node versions — engineering teams should track V8 release notes when upgrading Node.