V8 Orinoco concurrent marking write-barrier overhead per isolate under high concurrency

Concurrent marking contention across isolates

V8's Orinoco garbage collector performs concurrent marking on dedicated threads using a Dijkstra-style write barrier that adds overhead to every pointer write. When multiple isolates run in a single process — such as Node.js worker_threads — they share the same V8 platform and concurrent GC threads, creating cross-isolate interference that the embedding guide does not document.

Missing per-isolate concurrency control

The heuristic that triggers concurrent marking depends on heap size and allocation rate, yet there is no public API or flag to tune the marker thread's concurrency level per isolate. The global --max-concurrent-marking-threads flag (introduced in V8 v10.0) limits marker threads process-wide but does not isolate the effect per isolate or provide latency SLO guidance. Empirical reports indicate disabling concurrent marking via --no-concurrent-marking can reduce p99 latency by 10–30% under high concurrency, at the cost of longer major GC pauses.

Unresolved configuration question

Should the write barrier be made adaptive — for example, disabling concurrent marking for isolates with low allocation rates — to reduce tail latency? No such adaptation exists in current releases.

• Is there a documented threshold or heuristic for when concurrent marking transitions from beneficial to harmful for tail latency under multi-isolate workloads?
• Can an embedder configure per-isolate concurrent marking behavior without resorting to process-wide flags?
• What verification methodology does V8 recommend for measuring write-barrier contention impact on request latency in production embeddings?