Incremental, concurrent & parallel GC

Cleaning memory without freezing the page

The garbage collector is the part of the JavaScript engine that frees memory. It finds the objects your program can still reach and throws the rest away. You met it in the last few lessons.

To find what is still reachable, the collector must look at many objects. That takes time.

The simplest plan is to stop JavaScript and do all the work in one go. This is called a stop-the-world pause. While JavaScript is stopped, the page cannot react to typing, scrolling, or clicks. A long pause makes the page feel frozen.

So modern engines split the same work into smaller pieces, or let helpers do it at the same time as your code.

Two words you will see a lot:

• The main thread is the one line of work where your JavaScript runs. The page also answers clicks and draws itself there.
• A helper thread, or just a helper, is a second worker. It runs at the same time, on another core of the processor.

These plans change when and where the work runs. They do not change which objects stay. The collector still starts from the roots (starting points such as global variables), follows every reference, and keeps every object it reaches.

This lesson uses small JavaScript models. They show each plan in a few lines. They do not look inside your real browser engine.

The table compares each plan to cleaning a house. Read across: the plan's name, the house version, then what your page feels.

Three colors for marking

Marking is the collector's search for live objects. It starts from the roots and follows each reference to the next object.

Tri-color marking ("three-color marking") keeps track of that search with three colors:

• White: not seen yet.
• Grey: found, but the collector has not yet looked at the objects it points to.
• Black: found, and every object it points to has been looked at. This object is done.

When marking ends, every object that is still white was never reached. It is garbage.

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 to 5 build a small chain: user points to cart, and cart points to items.

Line 6 makes user grey, because the collector has found it. The other two are white.

The function markOne checks one object. In plain words, line by line:

1. Line 9 makes each object it points to grey.
2. Line 10 makes the object itself black.
3. Line 11 prints the three colors.

Lines 14 to 16 check the objects in order. The three logs are user black grey white, then cart black black grey, then items black black black.

Each row of the table is one color. Read across: what it means, then why the collector cares.

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 step-through calls the same markOne function as the code above. It saves the colors after every step, so you can step back. It replays the model. It is not a debugger inside a real engine.

Incremental marking: small slices

Incremental marking splits one marking job into short slices. The main thread marks a few objects, goes back to running your code, then marks a few more later.

Each pause is shorter, so the page stays responsive. The cost is some extra record keeping, because the collector must remember where it stopped.

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

Line 1 lists four objects to mark. Line 2 says to mark two objects in each slice. Line 3 prints 2: four objects in slices of two make two slices. Math.ceil rounds up, so a leftover object would still get its own slice.

Between the two slices, the page can do other work. In a real engine, some objects take longer to mark than others, so slices are not this even.

The playground below uses six objects. The picture shows them marked all at once, and in slices of two.

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 number of objects per pause. With 1, you get six pauses, and each one is as short as it can be. With 6, you get one pause that holds all six objects.

A real engine does not count objects like this. It gives each slice a time limit, and it also watches how fast your code makes new objects.

Concurrent marking: a helper works beside your code

Concurrent marking lets a helper thread mark objects while your JavaScript keeps running on the main thread. The main thread has less to do.

But your code can change references while the helper is looking. Say the helper has already finished the cart, so the cart is black. Then your code puts a white coupon into the cart. Nobody looks inside a black object again, so the coupon would never be checked. It could be thrown away while it is still in use.

A write barrier fixes this. You met write barriers in the last lesson: a small piece of engine code that runs every time your code stores a reference into an object. Here, the barrier turns the new white object grey. Grey objects are always checked before marking ends.

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

Line 1 starts with a cart that is black (done) and a coupon that is white (not seen). The comment on line 4 says what just happened: the app put the white coupon into the black cart. Line 5 is the barrier: it turns the coupon grey. Line 6 prints black grey.

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

Some objects are hard or unsafe for a helper to finish alone. One example is a host object: an object the browser provides, such as a page element.

A bailout worklist is a to-do list for those objects. The helper puts them on the list and moves on. Later, the main thread handles them at a safe moment. This is not a failure. It keeps the helper's job 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(","));

Line 1 is the helper's pile of ordinary objects. Line 2 is the bailout worklist, with one hard object. Lines 5 to 7 move that object to the main thread's pile. shift() takes the first item off a list.

Line 9 prints 2 hostObject. The helper still has two ordinary objects, and the main thread has the hard one.

To-do piles and work stealing

A marking worklist is the to-do pile of grey objects that still need checking. When several helpers work together, each one keeps its own pile. That way a helper can take its next object without asking the others first.

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

Line 1 gives the first helper three grey objects. Line 2 gives the second helper an empty pile. Line 3 moves two objects to the empty pile:

• splice(1) cuts out every item from position 1 onward.
• push(...) adds those items to the other pile.

Line 4 prints user cart,items.

Work stealing is this balancing step. A helper that runs out of work takes some from a fuller pile. Exactly how much it takes is up to the engine. What matters is that no helper sits idle while others are busy.

Work stealing only moves the collector's own to-do items between helpers. Your JavaScript does not move between threads.

Safepoints: planned places to pause

A safepoint is a place in running code where the JavaScript thread can stop and the engine can read its state safely. Think of a bus. It stops at bus stops, not in the middle of the road.

Sometimes the collector needs JavaScript to stop for a short step that cannot run at the same time as your code. Then it waits until your code reaches the next safepoint.

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 lists four steps. Two of them are "bus stop". Line 5 sets paused to true only at a bus stop. Line 8 prints paused safely.

Real safepoints sit in the engine's machine code, not in a list like this. The model only shows the idea of a planned stop.

Safepoints are why "concurrent" does not mean "no pauses". Helpers can do most of the work beside your code. But a few short pauses are still needed, for example to finish a step or to move objects safely. The win is shorter pauses on the main thread, not zero pauses.

Parallel copying and moving

Some collector steps can be shared by several helpers at once:

• Parallel scavenging. Scavenging is the quick clean of young memory: it copies the young objects that are still in use to a new place. In parallel scavenging, several helpers do that copying together.
• Parallel compaction. Compaction moves live objects close together, so the free memory is in one big piece. In parallel compaction, several helpers move objects and fix the references that point to them.

Both use several cores of the processor, so one collector step finishes 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 2 makes two empty piles. Line 4 deals the names out like playing cards. index % 2 is the remainder after dividing by 2, so objects 0 and 2 go to the first pile, and objects 1 and 3 go to the second. Line 6 prints cart,coupon items,address.

The model only splits names. Real copying also leaves a note at the old place saying where the object went, and updates every reference to it.

Moving objects needs care, because your code must never use an old memory address. Engines use their own records, barriers, and safepoints to make the move invisible. After compaction, your variable still points to the same object, even though the object now sits somewhere else in memory.

Idle-time cleaning and Orinoco

The browser draws the page as a series of pictures called frames. To look smooth, it draws about 60 frames a second, so each frame has about 16 milliseconds (ms).

Idle-time GC uses the spare time left in a frame, when the browser has some. It is like tidying up during an ad break on TV: it only works if there is a break. Typing, drawing, and network work can use up all the spare time. So idle time is a chance, not a promise.

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

Line 1 says the frame has 16 ms and the page used 11 ms. Line 2 works out 5 ms of spare time. Line 3 prints run idle GC, because 5 is at least the model's minimum of 3 ms. A busier frame would print wait.

V8 is the JavaScript engine inside Chrome and Node. Orinoco is the name of the V8 project that moved most of its collector work off the main thread. It made the collector mostly parallel and concurrent.

Orinoco is not something your JavaScript can call. It also does not promise the same behavior on every page. It names a direction: move more cleaning work off the main thread, whenever that stays correct.

What this means for your page

Your code does not choose how the collector plans its work. But it can make the collector's job easier or harder:

• Making lots of objects in a short burst gives it more work.
• Keeping data you no longer need keeps that data alive.
• Doing heavy work while the user types, or while an animation runs, leaves no spare time.

When a page stutters, measure first. Do not guess from a GC word in a log.

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

Line 1 sets the frame budget to 16 ms. Line 2 says the app's work takes 6 ms. Line 3 prints leave room. This does not mean the collector gets the other 10 ms. Drawing, input, and cleaning all share what is left.

When scrolling or typing janks (stutters), record a performance trace in your browser's developer tools. A performance trace is a recording of everything the page did over a few seconds.

When memory keeps growing, use the memory tools instead. Remove things that keep objects alive by accident, such as event listeners you no longer need and caches that grow forever.

The next lesson, Weak references & ephemerons, explains special references that do not keep objects alive. Do not use them in place of clear rules about which code owns which data.

Common misconceptions

• "Concurrent means no pause." Helpers work beside your code, but safepoints and finishing steps can still pause JavaScript for a short time.
• "Parallel means my callbacks run at the same time." It means several collector helpers share one step. Your JavaScript still runs one thing at a time.
• "Grey means garbage." Grey means found but not finished. It is exactly the work the collector still has to check. Objects still white at the end are the garbage.
• "Idle time is guaranteed." There is spare time only when the browser has some left over.
• "One log shows the exact schedule." When the collector runs depends on how fast your code makes objects, on the device, and on the engine version.

Each row of the table is one word that is easy to mix up. Read across: what it means, then what it does not mean.

All four plans aim for a page that stays responsive. Each one solves a different problem:

• Incremental keeps each pause short.
• Concurrent lets the work happen beside your code.
• Parallel uses more helpers, so one step finishes sooner.
• Idle-time uses spare time between frames.

Real engines combine them. They do not pick just 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, first decide what it is about: a color, a slice, a helper, or a planned place to pause.

Key takeaways

• White means not seen yet. Grey means found but not finished. Black means fully checked.
• Incremental marking splits the work into slices. Smaller slices make the longest pause shorter.
• Concurrent helpers need write barriers. They can leave hard objects on a bailout worklist for the main thread.
• Parallel helpers share work through to-do piles and work stealing. Safepoints are planned places where JavaScript can pause for a short step.
• Idle-time GC uses spare time in a frame. Orinoco is the V8 project that made its collector mostly parallel and concurrent.

Coming next: Weak references & ephemerons.