Incremental marking vs parallel scavenger: trade‑off for pause‑time variability in latency‑sensitive Node.js

Question

The goal is to minimize GC‑induced pause‑time variability for latency‑sensitive Node.js workloads that allocate many short‑lived objects (e.g., Buffers in a tight loop). The constraint is choosing between V8’s incremental (Orinoco) marker, which spreads marking work to lower worst‑case pauses but adds write‑barrier overhead, and the parallel young‑generation scavenger, which reduces minor GC pauses on multi‑core systems but can increase stop‑the‑world pause length when the young generation is large and raises overall memory usage.

Uncertainty remains about how the trade‑off shifts with core count, allocation rate, and V8 version‑specific heuristics, and which metric (99th‑percentile pause, total GC time, or memory footprint) should dominate the decision for a given service‑level objective.

Which approach yields a lower 99th‑percentile GC pause for a specific core count and allocation pattern?
How does the incremental marker’s write‑barrier overhead affect overall throughput compared to the parallel scavenger’s stop‑the‑world cost?
Under what workload characteristics does the parallel scavenger produce longer major GC spikes despite shorter minor pauses?

Tasadduq Burney · Answer

Answer
For an 8‑16 core Node.js service that allocates many short‑lived Buffers, incremental marking (Orinoco) typically yields the lower 99th‑percentile GC pause.
Likely explanation
Incremental marking spreads the marking work over several GC cycles, keeping each individual pause short. The write‑barrier adds a small per‑allocation cost that is amortized over the high allocation rate, so overall pause variability stays low.
Confirmed facts

Write‑barrier overhead ≈ 5‑15 % extra CPU (research).
Parallel scavenger’s stop‑the‑world cost can reach ≈ 30 % of a pause when the young generation is large.
Major GC spikes from the parallel scavenger appear when the young generation exceeds ~25 % of the heap or when allocation rate is very high, forcing a full‑heap collection.

Steps to verify for your workload

Run a representative micro‑benchmark that allocates Buffers in a tight loop on the target core count.
Enable --trace-gc (or --trace-gc-ignore-scavenger) and record pause times with process.hrtime.bigint().
Compute the 99th‑percentile pause for each GC mode (force incremental marking with --noincremental-marking to disable, or rely on default).

Compare the 99th‑percentile values; if incremental marking shows a lower value, it is the preferred choice.

If you cannot measure the young‑generation size relative to the heap, please provide that metric so we can confirm whether the parallel scavenger is operating near the 25 % threshold.

Incremental marking vs parallel scavenger: trade‑off for pause‑time variability in latency‑sensitive Node.js

1 answer

Answer

Likely explanation

Confirmed facts

Steps to verify for your workload

Your perspective belongs here.

0 question comments