Memory management & garbage collection

Memory you can reason about, not manually free

The stack-and-heap lesson gave you a careful mental model: variables can point to heap objects, and reachability decides whether an object is still needed. The closures lesson showed that functions can keep variables alive after their creator returns. Memory management joins those ideas and applies them to real frontend code.

You never call free() for ordinary JavaScript objects. You design code so unneeded objects stop being reachable: remove event listeners, clear timers, cap caches, and stop storing DOM nodes you removed. The exact garbage-collection run remains the engine's decision.

Step through this small feature. It creates a preview object, reads and mutates it, then removes the local reference. The console output is predictable; the later collection moment is not.

1function openPreview() {2  let preview = { title: "Cart", rows: ["hat", "bag"] };3  const label = preview.title.toUpperCase();4  preview.rows.push("coat");5  preview = null;6  return label;7}8 9console.log(openPreview());Run

Line 5 is the subtle line. preview = null is useful because it removes one path, but it is not a command to the garbage collector. If another root still reached the object, it would stay alive.

Garbage collectors start from roots: values the engine and host know must stay alive. From those roots, the collector follows references. If a root can reach an object, the object must be kept. If no root can reach it, the object is eligible for collection.

Generational collectors add an optimization on top of this model: most objects die young, so engines usually check young generations more often and promote survivors to older generations. That overview is enough here; engine internals differ, and normal code still reasons with reachability.

A simple reference-counting collector counts incoming references and frees an object when the count reaches zero. That idea breaks down with cycles: two objects can point at each other even after the rest of the program has lost them. Mark-and-sweep avoids that problem by starting from roots instead of trusting local counts.

1function markAndSweep(heap, roots) {2  const marked = new Set();3  const worklist = [...roots];4  while (worklist.length > 0) {5    const id = worklist.pop();6    if (!id || !heap[id] || marked.has(id)) continue;7    marked.add(id);8    for (const ref of heap[id].refs) worklist.push(ref);9  }10  const swept = Object.keys(heap).filter((id) => !marked.has(id));11  return { marked: [...marked], swept };12}13 14const heap = {Run15  app: { refs: ["modal"] },16  modal: { refs: ["user"] },17  user: { refs: ["profile"] },18  profile: { refs: [] },19  cycleA: { refs: ["cycleB"] },20  cycleB: { refs: ["cycleA"] },21};22const roots = ["app"];23const result = markAndSweep(heap, roots);24console.log(result.marked.join(", "));25console.log(result.swept.join(", "));

In the graph, cycleA and cycleB point at each other. A pure reference count would see one incoming reference for each object. The mark phase starts from app, never reaches the cycle, and the sweep phase can collect the whole unreachable island. This is still a simulation: it shows eligibility, not the browser's exact GC moment.

A leak is not “an object exists.” A leak is “something long-lived still reaches data the app no longer needs.” Frontend leaks often involve host roots: event targets, timers, retained closures, and caches that never shrink.

1const roots = ["app", "window", "timerQueue"];2 3function createMountedHeap() {4  return {5    app: { refs: ["component"] },6    window: { refs: ["resizeHandler"] },7    timerQueue: { refs: ["intervalCallback"] },8    component: { refs: ["bigRows"] },9    resizeHandler: { refs: ["bigRows"] },10    intervalCallback: { refs: ["bigRows"] },11    bigRows: { refs: [] },12  };13}14 15function reachableIds(heap) {16  const seen = new Set();17  const worklist = [...roots];18  while (worklist.length) {19    const id = worklist.pop();20    if (!heap[id] || seen.has(id)) continue;21    seen.add(id);22    worklist.push(...heap[id].refs);23  }24  return [...seen].filter((id) => !roots.includes(id));25}26 27function simulateUnmount(cleanup) {28  const heap = createMountedHeap();29  heap.app.refs = [];30  if (cleanup) {31    heap.window.refs = [];32    heap.timerQueue.refs = [];33  }34  return reachableIds(heap);35}36 37console.log(simulateUnmount(false).join(", "));38console.log(simulateUnmount(true).length);

Without cleanup, the simulated window listener and timerQueue still reach callbacks that close over bigRows. With cleanup, those roots are cut and the retained count drops to zero.

1const panel = document.querySelector("#listener-panel");2const controller = new AbortController();3const rows = ["Ada", "Lin"];4 5function renderRows() {6  console.log(rows.join(", "));7}8 9panel.addEventListener("click", renderRows, { signal: controller.signal });10panel.click();11controller.abort();12panel.click();13console.log("listener removed");

A listener on a long-lived target such as window can retain its callback and everything the callback closes over. Use removeEventListener, a listener option such as { once: true }, or an AbortController signal when the same cleanup action removes several listeners.

1const rows = ["Ada", "Lin", "Grace"];2const intervalId = setInterval(() => {3  console.log(rows.length);4  clearInterval(intervalId);5  console.log("interval cleared");6}, 0);

A setInterval callback remains reachable from the timer queue until you call clearInterval. If it closes over a large array, DOM node, or old component state, that data remains reachable too.

1function makeLeakyHandler() {2  const bigReport = ["sales", "inventory", "returns"];3  return () => console.log(bigReport.length);4}5 6function makeSmallHandler() {7  const rowCount = ["sales", "inventory", "returns"].length;8  return () => console.log(rowCount);9}10 11makeLeakyHandler()();12makeSmallHandler()();

The first handler captures a whole array. The second handler computes the primitive count and captures only that. The best fix is often to move large data out of the closure, not to avoid closures altogether.

1const cache = new Map();2 3function remember(key, value) {4  cache.set(key, value);5  if (cache.size > 2) {6    const oldestKey = cache.keys().next().value;7    cache.delete(oldestKey);8  }9}10 11remember("Ada", { visits: 1 });12remember("Lin", { visits: 2 });13remember("Grace", { visits: 3 });14console.log([...cache.keys()].join(", "));

1const metadata = new WeakMap();2let card = { id: "promo" };3metadata.set(card, { measured: true });4 5console.log(metadata.has(card));6card = null;7console.log("WeakMap keys are weakly held");

A normal Map strongly holds keys and values, so size caps, deletion, and clearing are real cleanup tools. A WeakMap is useful when metadata should not keep object keys alive by itself. You still cannot observe the exact moment a key is collected.

A DOM node is detached when it is no longer inside the document tree. It can still be reachable from JavaScript. This matters in UI code that stores old nodes in arrays, debug globals, module caches, event callbacks, or closure state after calling DOM methods like remove().

The runnable example below uses the lesson's RunContext page, which provides #leak-card. It removes that card from document, then proves the array still holds it.

1const retained = [];2const card = document.querySelector("#leak-card");3 4retained.push(card);5card.remove();6 7console.log(document.contains(card));8console.log(retained.length);9console.log(retained[0].textContent.trim());10 11retained.length = 0;12console.log(retained.length);

The important pair is document.contains(card) === false and retained.length === 1. The node is not in the document, but it is still reachable. Clearing the array removes this snippet's extra reference.

Finding leaks with Chrome DevTools

Normal page JavaScript cannot reliably ask “did GC run now?” Use tooling for leak investigations. In Chrome DevTools, open the Memory panel and collect evidence over repeated actions: mount and unmount a component, navigate away and back, or open and close a modal several times.

1. Heap snapshot: take one snapshot, perform the suspected leak action, take another, then switch to the Comparison view to find constructors whose retained counts grew.
2. Detached nodes: use the snapshot class filter for detached DOM terms and the Detached elements profile type when you want a focused list of elements retained by JavaScript references.
3. Allocation instrumentation on timeline: record allocations over time, select an interval, and inspect objects allocated in that interval that are still live at the end of the recording.
4. Allocation sampling: use it for lower-overhead, longer-running sessions when you need an approximate allocation breakdown by stack.

// Chrome-only and non-standard; do not build logic on this.
console.log(performance.memory);

// Needs cross-origin isolation headers before it is available.
if (crossOriginIsolated && "measureUserAgentSpecificMemory" in performance) {
  const result = await performance.measureUserAgentSpecificMemory();
  console.log(result.bytes);
}

Common misconceptions

Key takeaways

• JavaScript allocates objects as code runs and automatically collects unreachable ones later.
• Reachability starts at roots: globals, active stack frames, host queues, closures, handlers, and DOM structures.
• Mark-and-sweep collects unreachable cycles because it traces from roots instead of relying on local reference counts.
• Leaks usually come from long-lived roots: listeners, intervals, closures, unbounded caches, and retained detached DOM nodes.
• Use Chrome DevTools Memory tools to investigate; do not build app behavior around exact GC timing.

Up next: WeakRef & FinalizationRegistry, where the same nondeterministic timing warning becomes the main design constraint.