Why garbage collection?

Why garbage collection exists

Every object, array, function, closure, and DOM wrapper needs memory while your program can still use it. The hard part is knowing when that memory is no longer needed. JavaScript chooses automatic memory management: the engine and host cooperate to find objects the program can no longer reach, then reclaim their space.

A root is a starting point the runtime must treat as live, such as globals, current stack-frame locals, and host-held handles for timers or event listeners. Reachability means there is a path from a root to an object by following references. The object graph is the network formed by those objects and references.

This module begins after Exceptions & unwinding. The everyday memory lessons already cover memory management, stack and heap, WeakMap and WeakSet, WeakRef and finalization, and finding memory leaks. Here we go inside the engine. Heap layout is the companion lesson for heap spaces; later lessons will cover reference counting, mark-sweep, generational GC, write barriers, and incremental or concurrent GC.

Manual vs automatic memory management

Manual memory management gives the program direct responsibility. In C, code can ask for memory with malloc and return it with free. That control is useful, but the code must be exactly right. Using memory after it was freed, freeing it twice, or forgetting to free it can crash or leak.

1// C example: manual memory management, not browser JavaScript.2char *name = malloc(32);3strcpy(name, "Asha");4free(name);5printf("%s", name);     // bug: use-after-free6free(name);             // bug: double free7// If free(name) were forgotten, this allocation would leak.

JavaScript does not expose free(object). Instead, a collector decides when an object is unreachable. Line 2 below creates an object inside makeReceiptReader. Line 3 returns a function that still reads it. Because readTotal remains reachable on line 8, the receipt must remain reachable too.

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());

Automatic memory management removes an entire class of manual-memory bugs, but it does not make memory free. The collector needs time, metadata, and spare heap headroom. Your code still decides which references stay alive.

Roots and reachability

Reachability is a graph question. If a root can reach an object by following references, the object must be kept. If no root can reach it, it is garbage, even when it points to other unreachable objects.

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(","));

The snippet prints cart,items,root. The detached pair detachedA and detachedB is not printed, because no root path leads to either object. The cycle between them does not matter to a tracing collector.

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 is the collector's map

Real applications are bigger than the tiny snippet: a root might point to a cart, the cart might point to items, a detached pair might form a cycle, and an event listener might keep a closure alive. The collector sees one graph, not separate stories.

1const roots = ["window", "event-listener"];2 3window.cart = cart;              // toggle: root -> cart4cart.items = items;              // toggle: cart -> items5detachedA.friend = detachedB;    // cycle half 16detachedB.friend = detachedA;    // cycle half 27button.onclick = () => draftOrder.total; // toggle: listener -> closure data8 9const result = markFromRoots(roots, graph);10console.log(result.reachable, result.garbage);

This is why leak debugging often means looking for the first accidental root, not the biggest object. A large array is only a symptom if a root path still reaches it.

Real V8 evidence: weak-only objects can disappear

Browser JavaScript cannot force a collection, and production code should not depend on exactly when collection runs. For a lesson test, Node can expose V8's test hook with --expose-gc. The probe below waits for later tasks between gc() calls, because weak targets are cleared after the current job, not while your current expression is still using them.

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);

Use this as evidence of the reachability rule, not as an app technique. For everyday weak-reference patterns, link back to the published WeakRef and finalization lesson.

What the collector must balance

A collector has two jobs that pull against each other. It must find garbage accurately, and it must do that work without making the program feel slow or using too much memory. Engine teams choose algorithms and scheduling strategies to balance three pressures: throughput, latency, and memory overhead.

Throughput asks how much total time is left for useful work. Latency asks how long any one pause lasts. Memory overhead asks how much extra heap headroom, metadata, or copied space the strategy needs. The next lessons explore the individual algorithms; this first lesson keeps the trade-off vocabulary sharp.

Throughput, latency, and memory trade-offs

The same allocation pattern can be collected in different ways. Rare big collections keep JavaScript running longer between collections, but when the collector finally runs the pause can be large. Frequent small collections lower the worst pause, but may spend more total time collecting. More memory headroom can reduce collection frequency, but increases 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));

Modern engines mix techniques: later lessons will discuss generational collection, write barriers, and incremental or concurrent marking. For now, keep the vocabulary: throughput is total cost, latency is one pause, and memory overhead is headroom.

Stop-the-world pauses

A stop-the-world pause stops JavaScript while the collector performs work that must see a stable view. The page does not run your click handler or animation callback during that pause. This matters for 60 fps rendering, where one frame has about 16.7 ms for JavaScript, style, layout, paint, and compositing.

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 replay's third frame does only 5 ms of normal JavaScript work, but a 12 ms pause pushes it to 17 ms. That misses the 16.7 ms frame budget. If this idea is new, pair it with rendering performance.

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);

Practical developer habits

Most days, you do not tune the collector. You shape reachability. If a component is gone, remove listeners that close over its data. Clear timers and intervals. Drop cache entries when they stop being useful. Keep large temporary objects inside functions when possible so their stack roots disappear quickly.

• Use heap snapshots and allocation timelines before changing code.
• Remove unused event listeners, observers, and timers that keep closures reachable.
• Prefer bounded caches; document what owns each long-lived collection.
• Measure interaction latency before assuming GC is the bottleneck.
• Link to the everyday lessons for API details instead of duplicating them here.

Garbage collection is a safety net, not a substitute for ownership. The collector frees unreachable memory; it cannot decide whether your global cache should still be important.

Common misconceptions

• “Garbage means useless.” It means unreachable. A reachable object can still be a logical leak.
• “Cycles always leak.” A detached cycle is garbage for a tracing collector. A cycle leaks only when a root path remains.
• “GC runs immediately when a variable goes out of scope.” The object becomes eligible; the exact collection time is an engine choice.
• “WeakRef is a cleanup tool for normal app logic.” It is for advanced cases. Do not depend on finalization timing.
• “GC pauses are the same as total GC cost.” One long pause hurts latency even if total collection time is modest.

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));
}
// The component is removed, but the listener remains on the button.

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

Check your understanding

Answer by naming roots, tracing references, and keeping throughput, latency, and memory separate.

Key takeaways

• Garbage collection frees objects the program can no longer reach from roots.
• Roots include globals, current stack-frame locals, and host-held handles such as timers or listeners.
• The object graph decides reachability; unreachable cycles are still garbage.
• Collectors balance throughput, latency, and memory overhead, so pause length and total GC time are different questions.
• Stop-the-world pauses halt JavaScript and can matter when a frame has only about 16.7 ms.
• Developers should remove accidental roots and measure memory behavior before optimizing.

Coming next: Reference counting & cycles, the simple counting idea and why cycles make it tricky. Later lessons move into mark-sweep, generational collection, write barriers, and incremental or concurrent GC.