Why garbage collection?

Why garbage collection exists

Your program makes objects all the time: plain objects, arrays, functions, and more. Each one takes up memory. While your code can still use an object, its memory must stay. When no code can use it any more, the memory can be given back and used again.

The hard part is knowing when that moment comes. In JavaScript, you don't do this yourself. The engine does it for you. The engine is the part of the browser, or of Node, that runs your code.

A few words come up again and again in this lesson:

• A root is a starting point that JavaScript always treats as in use. Examples: global variables, the local variables of the function that is running now, and things the browser holds for you, such as a timer or an event listener.
• A reference is a link to an object. When cart.items holds an array, cart has a reference to that array.
• An object is reachable when you can start at a root and follow references until you get to it.
• The object graph is the map of all objects and the references between them.

This lesson comes after Exceptions & unwinding. Earlier lessons show memory from the outside: memory management, stack and heap, WeakMap and WeakSet, WeakRef and finalization, and finding memory leaks. This lesson looks inside the engine. Heap layout is a companion lesson about how the engine splits up its memory. Later lessons cover the main ways collectors work: reference counting, mark-sweep, generational GC, write barriers, and incremental or concurrent GC.

Freeing memory by hand vs automatically

Some languages make you free memory by hand. In C, you ask for memory with malloc. When you are done, you give it back with free. This gives you full control. But every step must be exactly right. Three mistakes are common:

• Using memory after you freed it. This is called "use after free".
• Freeing the same memory twice. This is called "double free".
• Forgetting to free memory. It is never given back. This is called a leak.

Each of these can crash the program or waste memory.

1// This is C, not JavaScript. Here you free memory by hand.2char *name = malloc(32);3strcpy(name, "Asha");4free(name);5printf("%s", name);     // mistake: used after it was freed6free(name);             // mistake: freed a second time7// If you forgot free(name), this memory would leak.

Line 2 asks for 32 bytes of memory. Line 4 gives them back. Line 5 still reads that memory after it was freed. Line 6 frees it a second time.

JavaScript has no free for objects. Instead, the garbage collector checks which objects can still be reached. Look at the code below:

1function makeReceiptReader() {2  const receipt = { customer: "Asha", total: 1200 };3  return function readTotal() {4    return receipt.total;5  };6}7 8const readTotal = makeReceiptReader();9console.log(readTotal());

• Line 2 makes a receipt object inside makeReceiptReader.
• Line 3 returns a function, readTotal, that still reads the receipt. A function that remembers variables from the place it was made is called a closure.
• Line 8 saves that function in a variable, also called readTotal.
• Line 9 calls it, and it prints 1200.

makeReceiptReader has finished, but the receipt is still needed. readTotal can still be reached, and it reads the receipt. So the receipt can be reached too, and JavaScript keeps it.

The table compares the two ways. Each row is one way of handling memory.

Automatic memory removes the mistakes of freeing by hand. But it still has a cost. The collector needs time to do its work. It also needs extra memory: some for its own notes, and some spare room. And your code still decides which references stay alive.

Roots and reachability

To decide what to keep, the collector asks one question about each object: can I get to it from a root by following references?

• If yes, the object is kept.
• If no, the object is garbage. This is true even when it points to other objects.

The code below acts out that question with plain arrays. Each name in graph lists the names it points to.

1const graph = {2  root: ["cart"],3  cart: ["items"],4  items: [],5  detachedA: ["detachedB"],6  detachedB: ["detachedA"],7};8 9function markFrom(roots) {10  const marked = new Set();11  const worklist = [...roots];12  while (worklist.length > 0) {13    const node = worklist.pop();14    if (marked.has(node)) continue;15    marked.add(node);16    for (const child of graph[node]) worklist.push(child);17  }18  return [...marked].sort();19}20 21console.log(markFrom(["root"]).join(","));

• Line 1 makes the graph. root points to cart, and cart points to items. detachedA and detachedB point only at each other. Objects that point at each other in a loop form a cycle.
• Line 9 starts markFrom. To mark an object means to put it on the "keep" list.
• Line 10 makes that list as a Set, a collection that holds each value only once. Line 11 makes a worklist: the names still waiting to be visited.
• Line 14 skips a name that is already marked. So a cycle can't keep the loop going forever.
• Line 15 marks one object. Line 16 adds the names it points to onto the worklist.
• Line 21 prints the marked names in alphabetical order.

It prints cart,items,root. detachedA and detachedB are not printed, because no path from root leads to them. They point at each other, but that doesn't help. A tracing collector only cares about paths from a root.

The step-through below runs a bigger version with two roots. One is globalThis, the global object that holds global variables. The other is a timer that the browser holds for you. Press Step to watch the marking, one line at a time.

1const graph = {Run2  globalThis: ["cart"],3  cart: ["items"],4  items: [],5  detachedA: ["detachedB"],6  detachedB: ["detachedA"],7  timer: ["callback"],8  callback: ["cache"],9  cache: [],10};11const roots = ["globalThis", "timer"];12 13function markFromRoots(names) {14  const marked = new Set();15  const worklist = [...names];16  while (worklist.length > 0) {17    const name = worklist.pop();18    if (marked.has(name)) continue;19    marked.add(name);20    for (const child of graph[name]) worklist.push(child);21  }22  return [...marked].sort();23}24 25console.log(markFromRoots(roots).join(","));

The object graph: one map of every object

Real apps are bigger than this small example. In one app, all of these can happen at once:

• A root points to a cart, and the cart points to its items.
• Two objects point only at each other.
• An event listener keeps a closure, and the closure keeps a big draft order.

The collector doesn't see these as separate stories. It sees one big map of objects and references: the object graph. In the playground below, each button adds or removes one reference. Press one, then check which objects are reachable and which are garbage.

1const roots = ["window", "event-listener"];2 3window.cart = cart;              // button: the root points to cart4cart.items = items;              // button: cart points to items5detachedA.friend = detachedB;    // A points to B6detachedB.friend = detachedA;    // B points to A7button.onclick = () => draftOrder.total; // button: the listener keeps the draft order8 9const result = markFromRoots(roots, graph);10console.log(result.reachable, result.garbage);

This is why finding a leak starts with the path, not with the size. In JavaScript, a leak is memory that stays reachable longer than you meant. A big array only stays because some path from a root still reaches it. So look for the first link on that path that shouldn't be there, such as a forgotten listener, timer, or global variable.

Proof in Node: an object with only a weak link goes away

You can't make the browser collect garbage when you want. Your app code should never depend on when a collection happens. But for a test, Node can help. Node runs JavaScript with V8, the same engine Chrome uses. If you start Node with the --expose-gc flag, it gives you a gc() function. Calling it asks V8 to collect garbage now.

The code also uses a WeakRef. A WeakRef is a weak reference: it lets you find an object, but it doesn't keep the object alive. Its deref() method gives back the object, or undefined once the object has been collected.

1const wait = () => new Promise((resolve) => setTimeout(resolve, 0));2 3function weakOnly() {4  let target = { label: "weak-only", data: new Array(1000).fill("x") };5  const weak = new WeakRef(target);6  target = null;7  return weak;8}9 10const rooted = { label: "rooted", data: new Array(1000).fill("y") };11const rootedRef = new WeakRef(rooted);12const weakRef = weakOnly();13let collected = false;14 15for (let attempt = 0; attempt < 8; attempt += 1) {16  await wait();17  globalThis.gc();18  await wait();19  if (weakRef.deref() === undefined) {20    collected = true;21    break;22  }23}24 25console.log(26  `Node ${process.versions.node} (V8 ${process.versions.v8.split(".").slice(0, 2).join(".")})`,27);28console.log("weak collected", collected);29console.log("root survives", rootedRef.deref()?.label);

• Lines 3 to 8: weakOnly makes an object on line 4 and wraps it in a WeakRef. Then it sets target to null. After that, only the weak reference points at the object.
• Line 10 makes rooted, a top-level const, so a root keeps it. Line 11 wraps it in a WeakRef too, only so we can check it later.
• Lines 15 to 23 try up to 8 times. Each time, they wait (line 16), call gc() (line 17), wait again (line 18), and check whether the weak object is gone (line 19).
• Lines 25 to 29 print the Node and V8 versions, whether the weak object was collected, and the label of the rooted object.

Why wait? JavaScript keeps the object of a new WeakRef alive until the code that is running now finishes. Each wait() uses setTimeout to let the current code finish and carry on a moment later. Only then can gc() clear the weak-only object.

Treat this as proof of the reachability rule, not as a way to write apps. For everyday uses of weak references, see the WeakRef and finalization lesson.

What the collector must balance

A collector has two jobs, and they pull against each other. It must find all the garbage correctly. And it must do that without making the program feel slow or use too much memory. Engine teams pick their methods to balance three things:

• Throughput: how much of the total time goes to your program's real work, instead of to collecting.
• Latency: how long one single pause lasts. While the collector pauses your code, the page can't respond.
• Memory overhead: how much extra memory the collector needs. This includes spare room, the collector's own notes, and garbage it hasn't cleared yet.

The next lessons show the collector's methods one by one. This lesson only names the three things they balance.

Throughput, latency, and memory: you can't win all three

The same program can be collected in different ways. Each way gives something up:

• Collect rarely, in big batches. Your code runs longer between collections. But when a collection comes, the pause is long.
• Collect often, in small batches. Each pause is short. But all the pauses together may take more time.
• Leave more spare memory. Collections happen less often. But the most memory in use at one time, called the peak, goes up.

Each row of the table is one thing a collector balances. The last column says what engines usually do about it.

The playground below makes new objects in 10 bursts, and each burst adds a few MB of memory. All three plans get the same bursts. Pick a plan. Then compare its longest pause, its total pause time, and its peak memory.

1const bursts = [10, 12, 9, 14, 8, 11, 13, 7, 12, 10];2 3function simulate(strategy) {4  let heap = 20;5  let totalPause = 0;6  for (const allocated of bursts) {7    heap += allocated;8    if (heap >= strategy.threshold) {9      totalPause += strategy.pause(heap);10      heap = strategy.reclaimTo;11    }12  }13  return totalPause;14}15 16console.log(simulate(frequentSmall));

Real engines mix several methods. Later lessons cover generational collection, write barriers, and incremental or concurrent marking. For now, remember three short meanings: throughput is the total cost, latency is the length of one pause, and memory overhead is the extra memory.

Stop-the-world pauses

A stop-the-world pause is a moment when JavaScript stops completely so the collector can work. The collector needs this for some of its work, because objects must not change while it looks at them. During the pause, the page can't run your click handler or your animation code.

This matters for smooth animation. Most screens show 60 pictures per second. Each picture is called a frame. So each frame has about 16.7 ms (1000 ms divided by 60). In that time, the browser must run your JavaScript and also draw the page. If a frame takes longer, the frame is missed and the animation stutters.

The step-through below draws three frames. Each one does 5 ms of work and adds 4 MB of new objects. When memory reaches 24 MB, the model pauses for a collection.

1const frameBudgetMs = 16.7;Run2let heapMB = 12;3 4function renderFrame(workMs, allocatedMB) {5  heapMB += allocatedMB;6  if (heapMB >= 24) {7    const pauseMs = 12;8    heapMB = 10;9    return workMs + pauseMs > frameBudgetMs ? "missed frame" : "smooth";10  }11  return workMs <= frameBudgetMs ? "smooth" : "missed frame";12}13 14console.log(renderFrame(5, 4));15console.log(renderFrame(5, 4));16console.log(renderFrame(5, 4));

The third frame does only 5 ms of normal work. But a 12 ms pause pushes it to 17 ms. That is over the 16.7 ms budget, so the frame is missed. If frames are new to you, read rendering performance too.

In Node, you can watch real V8 collections happen. The --trace-gc flag makes Node print one line for each collection.

1const keep = [];2for (let index = 0; index < 20000; index += 1) {3  keep.push({ index, data: new Array(20).fill(index) });4}5globalThis.gc();6console.log("kept objects", keep.length);

Line 1 makes an array that keeps every new object reachable. Lines 2 to 4 add 20,000 small objects to it. Line 5 calls gc(). Line 6 prints how many objects were kept.

What you do in everyday code

Most days, you don't change how the collector works. Instead, you control which references stay alive. When a part of your page goes away, also remove the things that still point at its data. These habits help:

• Measure first. Use heap snapshots and allocation timelines before changing code. These DevTools tools show what is in memory and when it was made.
• Remove event listeners, observers, and timers you no longer need. Each one can keep a closure, and its data, reachable.
• Give caches a size limit. Write down which part of the code owns each list or map that lives a long time.
• Keep big temporary objects inside a function. When the function returns, its local variables stop being roots.
• Check how slow an interaction really is before you blame the collector.
• For the details of each tool, such as WeakRef, use the everyday lessons linked at the top.

Garbage collection is a safety net. It doesn't decide which part of the code owns what. The collector frees memory that no root can reach. It can't tell whether your global cache still matters.

Common misconceptions

• “Garbage means useless.” Garbage means no root can reach it. An object can be reachable and still useless. That is a leak.
• “Cycles always leak.” Two objects that only point at each other, with no path from a root, are garbage. A cycle leaks only when a root still reaches it.
• “Memory is freed the moment a function returns.” When a function returns, its local objects only become ready to be collected, if nothing else points at them. When the collection actually runs is up to the engine.
• “WeakRef is a clean-up tool for normal app code.” It is for rare, advanced cases. Don't depend on when an object gets collected.
• “GC pauses and total GC time are the same thing.” One long pause makes the page feel slow, even when the total time spent collecting is small.

These words are easy to mix up. Each row says what a word means and what it does not mean.

Practice exercises

const graph = { root: ["cart"], cart: ["items"], items: [], a: ["b"], b: ["a"] };
const marked = new Set();
const worklist = ["root"];
while (worklist.length) {
  const node = worklist.pop();
  if (marked.has(node)) continue;
  marked.add(node);
  for (const child of graph[node]) worklist.push(child);
}
console.log([...marked].sort().join(","));

const strong = { name: "rooted" };
const weak = new WeakMap();
weak.set(strong, "metadata");
console.log(weak.get(strong));

function mark(node) {
  if (/* already visited? */) return;
  // mark node, then visit children
}

const marked = new Set();
function mark(node) {
  if (marked.has(node)) return;
  marked.add(node);
  for (const child of node.refs) mark(child);
}

function mount(button) {
  const draftOrder = { lines: new Array(10000).fill("item") };
  button.addEventListener("click", () => console.log(draftOrder.lines.length));
}
// This part of the page is removed, but the button keeps its listener.

const workMs = 5;
const pauseMs = 12;
console.log(workMs + pauseMs > 16.7 ? "missed frame" : "smooth");

Check your understanding

For each question, find the roots and follow the references. Keep throughput, latency, and memory apart.

Key takeaways

• Garbage collection frees objects that your program can no longer reach from a root.
• Roots include global variables, the local variables of running functions, and things the browser holds for you, such as timers and listeners.
• Following references from the roots decides what is reachable. Objects that only point at each other, with no path from a root, are still garbage.
• Collectors balance throughput, latency, and memory. The length of one pause and the total time spent collecting are different things.
• A stop-the-world pause stops JavaScript. It matters when each frame has only about 16.7 ms.
• Your job: remove links that keep memory reachable by mistake, and measure before you try to make things faster.

Coming next: Reference counting & cycles. Reference counting keeps a count of how many references point at each object. That lesson shows why cycles make counting hard. Later lessons cover mark-sweep, generational collection, write barriers, and incremental or concurrent GC.