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

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?