Garbage collection across engines & the DOM

One language rule, many collectors

A garbage collector (GC for short) is the part of a JavaScript engine that frees memory your program no longer needs. An engine is the program that runs your JavaScript, like V8 in Chrome.

JavaScript itself gives only one rule. An object may be freed once your running program can no longer reach it. The language doesn't say when the cleaning happens, how memory is laid out, or whether objects get moved. Each engine chooses those things, together with the browser or app around it, called the host.

Why does this matter? Your code should never count on a cleanup at one exact moment. But knowing the main strategies helps you read a memory tool. It also helps you see why a button you removed from the page can still stay in memory, held by a listener or a wrapper.

When you read an article about an engine, sort each sentence into one of two groups:

• A language rule tells you what your program can see. Example: an object can no longer be used once the last path to it is gone.
• An engine detail tells you how one engine does the work. Example: it uses a helper thread, or it moves objects that are still in use.

This habit saves you from a common debugging mistake. A heap snapshot is a saved picture of everything in memory. It may show a removed button today. It can't promise that the next cleanup runs right after one particular click. In V8, SpiderMonkey, JavaScriptCore, and Hermes, the useful question is the same: which root can reach this object right now?

V8: Orinoco and Oilpan

V8 is the engine in Chrome and Node.js. Its garbage-collection project is called Orinoco. Orinoco shares out the work in three ways: parallel, incremental, and concurrent. You'll see what each word means just below. V8 also has two kinds of cleanup:

• A quick, frequent cleanup of new objects, called the scavenger. Many new objects are thrown away soon, so checking them often frees memory quickly.
• A bigger cleanup of all objects. It marks every reachable object, sweeps away the rest, and can compact some pages. Compacting means moving the objects that are left close together.

function priceWithTax(price) {
  const total = price + 3;
  console.log(total);
}
priceWithTax(10);

Line 5 calls the function with 10. Line 2 makes total. Line 3 prints 13. When the call ends, no code can use total any more. JavaScript doesn't say when V8 will reuse that memory.

A browser is mostly written in C++, another programming language. The parts of a page, like buttons, are called the DOM, and they live in C++ memory. Each DOM button also has a JavaScript wrapper: the object your code holds, which stands for the C++ button. Chrome uses Oilpan, a garbage collector for C++ objects. Together with V8, Oilpan can follow references from JavaScript into C++ and back.

const work = ["mark", "sweep"];
console.log(work.join(" then "));

Line 1 makes a small list with two pieces of cleaning work. Line 2 prints mark then sweep. This code doesn't show V8's insides. It only names the work. A thread is a separate line of work that the computer can run next to others. Orinoco can share out the work in three ways:

• Parallel: JavaScript pauses, and several helper threads do the work at the same time.
• Concurrent: a helper thread does some of the work while your JavaScript keeps running.
• Incremental: the main thread does the work in small pieces, between pieces of your code.

None of these choices changes which reachable objects are kept.

A pointer is a memory address that points at an object. Your JavaScript code never sees C++ pointers, but the browser's own code uses them all the time. Following both sides together makes sure neither collector decides one side is garbage while the other side can still reach it.

SpiderMonkey: memory split into zones

SpiderMonkey is the engine in Firefox. Mozilla describes its collector with a long list of words. Here is what each one means:

• Tracing: it follows references from the roots.
• Precise: it knows exactly where every reference is, so it never has to guess.
• Incremental: it can do the work in small pieces.
• Generational: it sorts objects by age and checks new ones more often.
• Partly concurrent and parallel: some of the work runs on helper threads.
• Compacting: it can move objects that are left close together.

const user = { cart: { item: "tea" } };
console.log(user.cart.item);

Line 1 makes a path: from user to a cart object, then to the string "tea". Line 2 prints tea. A precise collector knows which properties hold references as it follows a path like this.

The heap is the memory where objects live. SpiderMonkey splits its heap into parts called zones. It can clean one zone on its own. Objects in different zones can still point to each other.

Inside a zone, objects sit in arenas: small blocks of heap memory of one fixed size. When SpiderMonkey compacts, it moves objects between arenas. So it must also update every reference to a moved object.

const zones = { account: ["user"], shop: ["cart"] };
console.log(Object.keys(zones).join(","));

Line 1 makes a small model with two named zones. Line 2 prints account,shop. A real zone is not a JavaScript property. It is a split inside the engine. It lets SpiderMonkey clean one zone at a time.

const arenas = [["user"], [], ["cart"]];
console.log(arenas.filter((arena) => arena.length).length);

Line 1 makes three arenas. The middle one is empty. Line 2 counts the arenas that hold something and prints 2. In a real compacting cleanup, the objects that are left may move, so empty arenas can be given back. SpiderMonkey says compacting updates every reference to moved objects. It also says compacting is not done in small pieces: it runs in one go.

Split into zones doesn't mean cut off. A user object in one zone can still point to a cart in another zone. A zone is just a smaller piece the collector can clean on its own. The engine keeps notes about references between zones. So a path that crosses zones is never lost during a cleanup.

JavaScriptCore: Riptide and stack scanning

JavaScriptCore is the engine in Safari. The WebKit team built a collector for it called Riptide. Riptide is concurrent: most of its work runs while your JavaScript keeps running. WebKit describes these parts of it:

• Helper threads share the marking work, in parallel.
• Write barriers: small checks that run when your code changes a reference, so the collector doesn't miss the change.
• Short stops at safe points: places in the code where the program can pause safely. Some steps need everything to hold still for a moment.

const cart = { item: "tea" };
const savedCart = cart;
console.log(savedCart.item);

Line 1 makes the cart. Line 2 makes a second reference to the same object. Line 3 prints tea. A real collector must find every path to an object, even while the app keeps changing those paths.

The stack is the memory that holds the local values of functions that are running. Native code is code the computer runs directly: the engine's own C++, or machine code the engine made from your JavaScript. On the stack, native code keeps plain numbers, and the collector can't always tell what a number means. If a number could be the address of an object, Riptide plays safe and treats it as a reference. This is called conservative scanning.

const words = [7, 42, 99];
console.log(words.includes(42) ? "pin" : "move");

Line 1 stores three plain numbers in this model. Line 2 prints pin, because 42 is in the list. Real engines don't check JavaScript values this way. WebKit checks the numbers on the stack against where objects really are in memory. This code only shows the safe choice.

Riptide also never moves objects. To tell old objects from new ones, it keeps a mark on each object between cleanups. It doesn't move the objects that are left into another area. That fits well with conservative scanning. If native code might still hold an object's address, leaving the object where it is is safer than moving it.

Conservative means careful. The collector would rather keep an object a little too long than free or move an object that native code might still use. That can waste some memory. But native code never ends up holding an address that points to nothing, called a dangling pointer, which could crash the program.

Hermes and Hades

Hermes is the JavaScript engine most React Native apps use. Its collector is called Hades. Hermes calls Hades mostly concurrent. It splits objects into two age groups:

• New objects, the young generation, get quick, frequent cleanups.
• Older objects, the old generation, get a mark-and-sweep cleanup. Most of that work runs on a background thread. It decides what to keep from the state of memory at the start of the cleanup.

Background work can make long pauses shorter. It still doesn't let your JavaScript know when a cleanup will happen.

const order = { item: "tea", count: 3 };
console.log(order.count);

Line 1 makes one object. Line 2 prints 3. Hermes might keep this object with the young objects, move it to the old ones later, or free it. Your JavaScript can't choose.

const youngOrders = ["tea", "book"];
console.log(youngOrders.length);

Line 1 makes two order names. Think of them as new objects. Line 2 prints 2. A collector that sorts objects by age is called generational. It checks new objects more often, because many of them are thrown away soon. This only makes cleaning faster. It doesn't promise that one order is freed first.

Use the same good habits in a browser or in a mobile app:

• Remove listeners you no longer need.
• Clear timers you no longer need.
• Keep caches small.
• Measure a real problem with a memory tool before you change how your code makes objects.

"Mostly concurrent" is a reason not to trust one smooth test run. The collector may still need short pauses. It may also behave differently on another phone. Measure on the devices and screens that matter. Then remove whatever holds on to memory by mistake, before you change how your code makes objects.

Tracing JavaScript and C++ together

A button on a web page is not only a JavaScript object. Your code sees the wrapper, the JavaScript object. The browser also keeps its own C++ data for the button. A listener function can hold on to the wrapper. Before the collector frees either part, it must follow the references in both directions.

const button = document.createElement("button");
button.textContent = "Buy";
button.onclick = () => console.log(button.textContent);
console.log(button.textContent);

Line 1 makes the button. Line 2 sets its text. Line 3 stores a listener function that uses button. So the listener holds a reference back to the wrapper. Line 4 prints Buy.

The wrapper also stands for the C++ object that is the real button. Each browser links the two in its own way. But the collector can't treat the JavaScript side and the C++ side as two separate piles. Oilpan, working with V8, is one documented way to follow references across both sides.

const page = { button: "button" };
const listener = { button: page.button };
delete page.button;
console.log(listener.button);

Line 1 makes a small model of a page. Line 2 copies the button into a listener model. Line 3 deletes the page's property. Line 4 still prints button, because the listener has its own path to it.

A retaining path is the chain of references from a root that keeps an object alive. On a real page, look at the retaining path before you assume that removing a node removed every path to it.

The step-through and the playground below use a small model of a button. Each name stands for one part:

• window: the root.
• js-button: the JavaScript wrapper.
• js-listener: the listener function.
• cpp-button: the browser's C++ button.

1const roots = ["window"];Run2const graph = {3  window: ["js-button"],4  "js-button": ["cpp-button", "js-listener"],5  "js-listener": ["js-button"],6  "cpp-button": ["js-button"],7};8const result = traceBothHeaps(roots, graph);9console.log(result.reachable.join(","));

const roots = ["window"];
const graph = {
  window: ["js-button"],
  "js-button": ["cpp-button", "js-listener"],
  "js-listener": ["js-button"],
  "cpp-button": ["js-button"],
};

console.log(traceBothHeaps(roots, graph).join(","));

Conservative stack scanning

Conservative stack scanning works like this: when a number on the native stack looks like an object's address, the collector treats it as a reference. So it never frees an object that native code still uses. The cost is false retention: a plain number may just happen to look like an address, so an unused object is kept.

const objectAddress = 42;
const stackWords = [7, 42, 99];
const pinned = stackWords.includes(objectAddress);
console.log(pinned ? "kept and pinned" : "can move");

Line 1 gives the object a pretend address, 42. Line 2 puts 42 among the stack numbers. Line 3 finds the match. Line 4 prints kept and pinned. This is a model. It doesn't show real addresses in your browser.

If the engine can't tell whether a number is really a pointer, moving the object could make that pointer wrong. Keeping the object in place is safer. An object that must stay in place is called pinned. That is why conservative scanning can stop some objects from being compacted.

1const address = 42;Run2const stackWords = [7, 42, 99];3const result = scanConservatively(stackWords, address);4console.log(result.state);

const address = 42;
const stack = [7, 42, 99];
console.log(stack.includes(address));

Compare the engines

The names below are useful starting points. They don't promise that every version of an engine works the same way. All four engines may change how they clean, while JavaScript keeps working the same.

Read each row as: this engine, how its collector works, and why that matters to you.

The table only gives the big picture. It tells you which engine a memory report or an article is about. It doesn't let your code count on a certain pause, address, or cleanup time.

What web developers should do

Different collectors don't change the first question to ask when you debug memory: which root still reaches this object? A removed button with a listener can stay in memory because your code, the browser, or a cache still points to it.

Start with the memory tools in the browser or in React Native. Look at the retaining paths, remove references you didn't mean to keep, and then measure again. A WeakRef holds an object without keeping it alive. Don't add a WeakRef just to hide a problem you don't understand yet.

Common misconceptions

• "All engines clean memory the same way." They all follow the same JavaScript rules. But each engine cleans in its own way.
• "A button removed from the page is freed at once." A listener, a wrapper, a cache, or a browser reference can still hold it.
• "A number that matches an address proves the object is in use." It is only a safe guess. It can keep memory that nobody needs.
• "Forcing a cleanup fixes a leak." A leak is usually a path you didn't mean to keep. A cleanup can't free anything that path still reaches.

Each row below names a term, says what it means, and says what it does not mean.

Practice exercises

const graph = { root: ["js"], js: ["cpp"], cpp: [] };
console.log(graph.root.length + graph.js.length + graph.cpp.length);

const words = [3, 42];
console.log(words.includes(42) ? "pinned" : "movable");

Check your understanding

Start with the shared rule: what can a root reach? Then name the engine feature or browser link that changes how the collector follows that rule.

Key takeaways

• JavaScript sets the rules your code can see. Each engine chooses how to clean memory.
• Orinoco (V8), SpiderMonkey's zones, Riptide (JavaScriptCore), and Hades (Hermes) are four different documented designs.
• A DOM button has a JavaScript wrapper and C++ data, so a full trace follows both sides.
• Conservative scanning picks safety over certainty, and it can pin objects in place.
• For a real leak, look at the retaining paths and remove references you didn't mean to keep.

Coming next: Heap snapshots in depth, where you read retaining paths and object sizes in a memory tool.