Incremental, concurrent & parallel GC

Keeping collection responsive

A tracing collector must eventually inspect a large graph of objects. Doing every part in one long stop-the-world pause is simple, but a page cannot respond to typing, scrolling, or clicks while JavaScript is stopped. Modern engines therefore schedule the same basic work in smaller or overlapping pieces.

These words describe when and where collector work runs. They do not change JavaScript reachability. The engine still starts from roots, follows references, and preserves objects the program can reach. This lesson uses small models so the scheduling is visible without pretending to inspect your browser engine.

Tri-color marking

Tri-color marking is a checklist model for a tracing collection. White means not looked at yet. Grey means found, but its references have not all been opened. Black means the object and its outgoing references have been fully checked for this marking cycle.

1const graph = {2  user: ["cart"],3  cart: ["items"],4  items: [],5};6const colors = { user: "grey", cart: "white", items: "white" };7 8function markOne(name) {9  for (const child of graph[name]) colors[child] = "grey";10  colors[name] = "black";11  console.log(name, colors.user, colors.cart, colors.items);12}13 14markOne("user");15markOne("cart");16markOne("items");

Lines 1 through 5 make user -> cart -> items. Line 6 starts user as grey because the marker has found it. Line 9 greys each child, and line 10 blacks the object after its drawer has been opened. The three logs print user black grey white, then cart black black grey, then items black black black.

1const graph = {Run2  user: ["cart"],3  cart: ["items"],4  items: [],5};6const colors = { user: "grey", cart: "white", items: "white" };7 8function markOne(name) {9  for (const child of graph[name]) colors[child] = "grey";10  colors[name] = "black";11  console.log(name, colors.user, colors.cart, colors.items);12}13 14markOne("user");15markOne("cart");16markOne("items");

The replay calls the same markOne function as the source. It records each color snapshot so you can step backward without seeing a later value early. It is a guided replay of a teaching model, not a debugger paused inside V8.

Incremental marking

Incremental marking splits one marking job into short slices. The main JavaScript thread marks some objects, returns to app work, then marks more later. Smaller slices can reduce the longest visible pause, although the collector needs extra bookkeeping between slices.

1const work = ["user", "cart", "items", "price"];2const sliceSize = 2;3console.log(Math.ceil(work.length / sliceSize));

Line 1 names four pieces of work. Line 2 chooses two objects per pause. Line 3 prints 2, because four objects need two slices of two. Between those two model pauses, the page can handle other work. The engine does not promise that every real object costs the same amount to mark.

1const work = ["user", "cart", "items", "price", "coupon", "address"];2 3function markInSlices(sliceSize) {4  let pauses = 0;5  let longestPause = 0;6  for (let start = 0; start < work.length; start += sliceSize) {7    const slice = work.slice(start, start + sliceSize);8    pauses += 1;9    longestPause = Math.max(longestPause, slice.length);10    // The app can run between these slices.11  }12  return { pauses, longestPause };13}14 15console.log(markInSlices(2).pauses, markInSlices(2).longestPause);

Change only the slice size. A size of one produces more pauses but the shortest modeled pause. A size of six produces one pause for this six-object list. In a real engine, a scheduler uses time budgets and allocation pressure instead of simply counting object names.

Concurrent marking and bailout work

Concurrent marking lets a helper thread trace ordinary objects while the JavaScript thread continues running. That overlap can reduce main-thread work, but the app may change references while the helper is looking. This is why the write-barrier idea from the previous lesson returns here.

1const colors = { cart: "black", coupon: "white" };2 3function storeCartCoupon() {4  // The app stores a white object into a black object.5  colors.coupon = "grey";6  console.log(colors.cart, colors.coupon);7}8 9storeCartCoupon();

Line 1 starts with a fully checked black cart and an unseen white coupon. Line 5 models an app write. The barrier on line 5 turns the coupon grey, and line 6 prints black grey. Without that repair, a black object could hide a live white child from the marker.

1const colors = { cart: "black", coupon: "white" };Run2 3function storeCartCoupon() {4  // The app stores a white object into a black object.5  colors.coupon = "grey";6  console.log(colors.cart, colors.coupon);7}8 9storeCartCoupon();

Some things are awkward or unsafe for a helper to finish alone. A bailout worklist is a list of those objects: the helper records them, then the main thread handles them at an appropriate safe point. It is not a failure; it is a way to keep concurrent work simple and correct.

1const helperPile = ["cart", "items"];2const bailoutWorklist = ["hostObject"];3const mainThreadPile = [];4 5while (bailoutWorklist.length) {6  mainThreadPile.push(bailoutWorklist.shift());7}8 9console.log(helperPile.length, mainThreadPile.join(","));

Lines 1 and 2 separate normal helper work from one hard object. Lines 5 through 7 move that object to the main-thread pile. Line 9 prints 2 hostObject: two ordinary objects remain in the helper pile and the main thread receives the bailout item.

Worklists and work stealing

A marking worklist is the pile of grey objects that still need checking. With several helpers, each can keep its own pile. Local piles avoid constant coordination, because a helper can take its next object without asking every other helper first.

1const helperOne = ["user", "cart", "items"];2const helperTwo = [];3helperTwo.push(...helperOne.splice(1));4console.log(helperOne.join(","), helperTwo.join(","));

Line 1 starts one helper with three grey objects. Line 3 moves two into the empty helper's pile. Line 4 prints user cart,items. The precise split is an engine choice; the important point is that idle helpers can become useful again.

Work stealing is that balancing step. A helper that finishes early takes some work from a fuller pile. It does not mean user JavaScript moves between threads. It is collector workers sharing collector bookkeeping during a parallel phase.

Safepoints

A safepoint is a place where the JavaScript thread can pause and the engine can understand its live state. Think of a bus: it stops at bus stops, not in the middle of the road. A collector sometimes needs this cooperation for a short phase that cannot safely overlap arbitrary execution.

1const steps = ["run handler", "bus stop", "run handler", "bus stop"];2let paused = false;3 4for (const step of steps) {5  if (step === "bus stop") paused = true;6}7 8console.log(paused ? "paused safely" : "keep running");

Line 1 includes two planned bus stop entries. Line 5 changes paused only at those entries. Line 8 prints paused safely. This tiny model does not represent machine instructions; it shows why an engine chooses coordination points.

Safepoints explain why “concurrent” is not the same as “zero pauses.” Helpers can do a lot beside the app, while short coordinated pauses still establish a stable view, finish a phase, or move objects safely. The payoff is smaller main-thread interruptions, not an impossible promise of none.

Parallel scavenging and compaction

Parallel scavenging lets several workers copy young live objects at the same time. Parallel compaction lets several workers move objects and update references during a compacting phase. These phases use multiple cores to finish one collector job sooner.

1const youngSpace = ["cart", "items", "coupon", "address"];2const helpers = [[], []];3 4youngSpace.forEach((name, index) => helpers[index % 2].push(name));5 6console.log(helpers[0].join(","), helpers[1].join(","));

Line 1 lists four young objects. Line 4 puts alternate names in two helper piles. Line 6 prints cart,coupon items,address. The model only divides names; real copying also installs forwarding information and updates every reference to moved objects.

Moving memory needs coordination because app code must not keep an old address. Engines use metadata, barriers, and safepoints to make the move invisible to JavaScript. Your variable still points at the same logical object after compaction, even though the engine changed where that object sits in memory.

Idle-time GC and Orinoco

Idle-time GC uses spare time between frames when the browser offers it. Like cleaning during a TV ad break, it is useful only when there is time left. Input, rendering, and network work can remove that spare time, so it is an opportunity rather than a deadline.

1const frame = { workMs: 11, budgetMs: 16 };2const spareMs = frame.budgetMs - frame.workMs;3console.log(spareMs >= 3 ? "run idle GC" : "wait");

Line 1 gives a frame 16 ms and says the page used 11 ms. Line 2 calculates 5 ms spare time. Line 3 prints run idle GC because five is at least the model's three-millisecond minimum. A busy frame would print wait instead.

Orinoco is V8's project name for work that made its collector mostly parallel and concurrent. It is not a JavaScript API and it does not guarantee one fixed behavior for every page. It names an engineering direction: move more collection work off the main thread when correctness allows.

What this means for a page

Most application code does not choose a collector mode. It can still make the collector's job easier or harder by allocating large bursts, retaining unnecessary data, or doing heavy work during input and animation. The first move is to measure the page, not to guess from a GC term in a log.

1const frameBudget = 16;2const appWork = 6;3console.log(appWork < frameBudget ? "leave room" : "too busy");

Line 1 names a simple frame budget. Line 2 represents six milliseconds of app work. Line 3 prints leave room. This is not a rule that GC gets the other ten milliseconds; it is a reminder that rendering, input, and collection all compete for responsiveness.

Use a performance trace when scrolling or typing janks. Use heap tools when memory grows. Remove accidental roots such as unused listeners and unbounded caches. The next lesson, Weak references & ephemerons, explains special weak edges; do not use them as a substitute for clear ownership.

Common misconceptions

• “Concurrent means no pause.” Helpers overlap work, but safepoints and finishing work can still pause JavaScript briefly.
• “Parallel means my callbacks run at once.” It means collector workers share a GC phase, not that ordinary JavaScript loses its single-threaded rules.
• “Grey means garbage.” Grey means discovered but unfinished; it is exactly the work that must be checked.
• “Idle time is guaranteed.” It is spare time only when the browser has it.
• “A trace proves the exact schedule.” Collection timing changes with allocation, device, and engine version.

The shared goal is responsiveness, but each tool solves a different constraint. Incremental work limits one pause, concurrent work overlaps the app, parallel work uses more workers, and idle-time work uses spare scheduling gaps. Engines combine them rather than selecting exactly one.

Practice exercises

const colors = { user: "grey", cart: "white" };
colors.cart = "grey";
colors.user = "black";
console.log(colors.user, colors.cart);

const work = ["user", "cart", "items", "price"];
const size = 2;
console.log(Math.ceil(work.length / size));

const colors = { cart: "black", coupon: "white" };
if (colors.cart === "black" && colors.coupon === "white") colors.coupon = "grey";
console.log(colors.coupon);

Check your understanding

For each question, identify whether it is about a color, a slice, a helper, or a planned coordination point.

Key takeaways

• White is unvisited, grey is discovered but unfinished, and black is fully checked in a marking cycle.
• Incremental marking splits work into pauses; smaller slices can reduce the longest pause.
• Concurrent helpers need barriers and may leave special objects on a bailout worklist.
• Parallel workers use worklists and stealing to divide collector work; safepoints coordinate short pauses safely.
• Idle-time work uses spare frame time, while Orinoco is V8's mostly parallel and concurrent collector project.

Coming next: Weak references & ephemerons.