Memory management & garbage collection

Memory that cleans itself up, with your help

Every object your code makes takes up some of the computer's memory. When the object is no longer needed, that memory should be given back. In JavaScript you don't give it back yourself. The engine does it for you.

Two earlier lessons help here. In the stack and heap lesson, you saw that a variable can point to an object. In the closures lesson, you saw that a function can keep using variables after the function that made them has finished. This lesson puts both ideas together in real web page code.

Some languages have a free() command to give memory back. JavaScript has no such command for objects. Your job is different: stop holding on to things you no longer need. You will learn four ways to do that:

• Remove event listeners you no longer need.
• Stop timers.
• Put a size limit on caches (stores of saved results).
• Stop keeping page elements you already removed.

The engine still decides when the clean-up happens. Your code can't choose the moment.

The three steps have short names. You will see them in other articles too:

• Allocate: find memory for a new value. This happens on its own when your code makes an object.
• Use: read or change the value.
• Release: let go of the value, so it can be cleaned up.

One more word you will see a lot. A reference is an arrow from a variable (or a property) to an object. The variable doesn't hold the object itself. It holds the arrow.

The table below shows each step. Read each row as: "in this step, my code does this, and this is the careful way to say it."

Step through this small example. It makes a preview object, reads it, changes it, and then lets go of it. You can know what it prints. You can't know when the old object is cleaned up.

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 needs care. preview = null removes one arrow to the object. It is not an order to the garbage collector. If something else still had an arrow to the object, the object would stay.

How does the garbage collector know what is still needed? It starts from roots. A root is a starting point that is always kept, such as a global variable. From each root, the collector follows the arrows to objects, then the arrows inside those objects, and so on.

• If the collector can get to an object this way, the object is reachable. It must be kept.
• If it can't, the object is unreachable. It may now be cleaned up. We say it is eligible for clean-up.

Here are the roots you will meet most often. Read each row as: "this is a starting point, and this is how it can keep memory in use."

Now some code. Two variables can point to the same object. Removing one arrow leaves the other.

let cart = { items: ["tea"] };
const saved = cart;
cart = null;
console.log(saved.items[0]);

• Line 1 makes a cart object. cart points to it.
• Line 2 copies the arrow into saved. Now two variables point to the same cart.
• Line 3 sets cart to null. That removes only the first arrow.
• Line 4 still prints tea, through saved.

A property is an arrow too. Here the cart is stored inside a page object.

const page = { cart: { items: ["tea"] } };
let selected = page.cart;
selected = null;
console.log(page.cart.items[0]);
delete page.cart;
console.log("cart" in page);

• Line 2 makes selected point to the same cart as page.cart.
• Line 3 clears only selected.
• Line 4 still prints tea, through page.cart.
• Line 5 uses delete to remove the cart property from page. Line 6 checks with in, so it prints false.

Deleting a property removes that one arrow. If some other variable still pointed to the cart, the cart would stay.

One more fact about real engines. Most objects are needed only for a very short time. So engines keep new objects in a separate area and check that area more often. Objects that last longer move to an "old" area that is checked less often. This is called generational collection. Each engine does it a bit differently. You still think about your code the same way: is the object reachable or not?

An old way to clean up is called reference counting. Each object keeps a count of how many arrows point to it. When the count drops to zero, the object is cleaned up.

Reference counting fails with a cycle: two objects that point at each other. Say the rest of the program loses both of them. Each one still has one arrow pointing to it, from the other. So neither count ever reaches zero, and neither is cleaned up.

Modern engines use mark and sweep instead. It has two steps:

1. Mark: start at the roots, follow every arrow, and put a mark on each object you reach.
2. Sweep: clean up every object that has no mark.

The example below acts out mark and sweep with plain JavaScript data. Each object has a name and a list of the names it points to. The root is app. Step through it and watch which names get marked.

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

Lines 19 and 20 make cycleA and cycleB point at each other. Reference counting would find one arrow into each, so it would keep both. Mark and sweep starts from app and never reaches them. So the sweep step removes both.

This is a model, written in JavaScript so you can run it. It shows which objects may be cleaned up. It doesn't show when the browser actually does it.

A memory leak is memory that stays in use even though the app no longer needs it. An object existing is not a leak. A leak is when something that lives a long time still points to data the app is done with.

In web pages, the long-lived thing is often one of these:

• An event listener on window or document.
• A timer made with setInterval.
• A closure that one of those keeps.
• A cache that only ever grows.

The playground below acts out a page part, called a component, being removed. Removing a component is called unmounting. The component had a big list called bigRows. It also added a window listener and a timer, and both use bigRows. Switch clean-up on and off and watch what is still reachable.

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 clean-up, window still holds the resize listener, and the timer list (timerQueue) still holds the timer function. Both functions use bigRows, so all three stay reachable. With clean-up, those two arrows are cut, and the count drops to zero.

The next example uses an AbortController. It is a small object with an abort() method. You pass its signal when you add a listener. Calling abort() later removes that listener.

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

• Line 9 adds a click listener and passes the controller's signal.
• Line 10 clicks the panel, so Ada, Lin prints.
• Line 11 calls abort(), which removes the listener.
• Line 12 clicks again. Nothing prints, because the listener is gone.

A listener on something that lasts as long as the page, like window, keeps its function. It also keeps everything that function uses. There are three ways to remove a listener:

• Call removeEventListener with the same function.
• Add it with { once: true }, so it removes itself after it runs once.
• Use an AbortController signal. One abort() call can remove many listeners.

const button = new EventTarget();
let clicks = 0;
const onClick = () => clicks++;
button.addEventListener("click", onClick);
button.removeEventListener("click", () => clicks++);
button.dispatchEvent(new Event("click"));
console.log(clicks);
button.removeEventListener("click", onClick);
button.dispatchEvent(new Event("click"));
console.log(clicks);

• Line 5 writes a new arrow function. It looks the same, but it is a different function. So it removes nothing.
• Line 6 fires a click, so line 7 prints 1.
• Line 8 passes the real onClick, so the listener is removed.
• Line 9 fires another click, but nothing runs. Line 10 prints 1 again.

So keep the function in a variable. You will need it to remove the listener.

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

setInterval runs a function again and again. The browser keeps that function in its timer list until you call clearInterval. Here, line 4 stops the timer the first time it runs, so 3 and then interval cleared print once. If the function used a big array, a page element, or old data, all of that stays reachable until the timer is stopped.

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

Both functions print 3. The difference is what they keep:

• The first function uses bigReport, so it keeps the whole array.
• The second works out the count first (line 7). Its function keeps only the number 3.

Closures are fine. The fix is to keep big data out of a closure that lives a long time.

let rows = ["tea", "hat"];
const showCount = () => console.log(rows.length);
rows = [];
showCount();

Line 2 makes a function that reads rows when it runs, not when it is made. Line 3 puts a new, empty array in rows. So line 4 prints 0. Nothing points to the old array any more, so it can be cleaned up.

A cache is a store of saved results, so you don't have to work them out again. A Map keeps everything you put in it. So a cache needs a size limit.

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

Line 4 adds an entry. If the map now has more than two entries, line 6 finds the oldest key, and line 7 deletes it. After three calls, only Lin, Grace is left.

const recent = [];
for (const item of ["tea", "hat", "bag"]) {
  recent.push(item);
  if (recent.length > 2) recent.shift();
}
console.log(recent.join(", "));

This list drops its oldest item with shift() when it grows past two. After the loop, line 6 prints hat, bag. A search-history list can use the same limit. Neither an array nor a Map gets smaller on its own.

A WeakMap is a map whose keys are objects. It holds its keys weakly: being a key in a WeakMap does not, by itself, keep an object alive.

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

Line 3 stores a fact about card, using the card as the key. Line 5 prints true. After line 6, nothing else points to the card. The WeakMap entry doesn't keep it alive, so the card and its entry can both be cleaned up.

const metadata = new WeakMap();
const cart = {};
metadata.set(cart, "tea");
console.log(metadata.has(cart));
console.log(typeof metadata.size);

Line 4 prints true. Line 5 prints undefined, because a WeakMap has no size, and you can't loop over it. To sum up:

• A normal Map keeps its keys and values. Use a size limit, delete, or clear() to let go of them. Use it when you need to list the entries.
• A WeakMap doesn't keep its keys alive. Use it for extra facts about objects.
• Neither one tells you when a key is cleaned up.

Each element on a web page is a DOM node: an object that stands for that part of the page. You can take a node off the page with DOM methods like remove().

A removed node is called detached: it is no longer part of the page. But JavaScript can still have an arrow to it. Then it must be kept. This happens when your code stores old nodes in places like these:

• an array or a Map
• a global variable you added for debugging
• a closure or an event listener

The example below runs on a small practice page made for this lesson. The page has a card with the id #leak-card. The code takes the card off the page, then shows that an array still holds it.

1const retained = [];2let 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;12card = null;13console.log(retained.length);

• Line 2 finds the card. Line 4 puts it in the retained array too.
• Line 5 takes the card off the page.
• Line 7 asks the page whether it still has the card. It prints false.
• Line 8 prints 1, because the array still holds the card. Line 9 even reads its text: Temporary card.
• Line 11 empties the array, and line 12 sets card to null. That removes both arrows this code had. Line 13 prints 0.

Removing both arrows makes the card eligible for clean-up. It doesn't clean it up right away.

function closeCard() {
  const card = document.querySelector("#leak-card");
  const onResize = () => console.log(card.textContent.trim());
  window.addEventListener("resize", onResize);
  card.remove();
  window.dispatchEvent(new Event("resize"));
  window.removeEventListener("resize", onResize);
}
closeCard();
console.log("closed");

• Line 4 adds a resize listener to window. The listener uses card.
• Line 5 takes the card off the page. Line 6 fires a resize event. The listener can still read the card, so it prints Temporary card.
• Line 7 removes the listener.
• When closeCard() ends, its card variable is gone too. The last line prints closed.

One more case. If a listener is added to the removed node itself, and nothing else points to that node, the listener doesn't keep the node alive. Both can be cleaned up together.

Finding leaks with Chrome DevTools

Your page's code can't reliably ask "was this object cleaned up just now?" To hunt for a leak, use the browser's tools instead. In Chrome DevTools, open the Memory panel.

Then repeat one action several times, for example:

• show a component and remove it,
• go to another page and come back,
• open a pop-up box and close it.

The Memory panel has four tools for this:

1. Heap snapshot: a snapshot is a list of every object in memory at one moment. Take one first. Then do the action and its clean-up several times, and take another. Choose the Comparison view to see which kinds of object grew in number. Click a suspect object to see its retaining path: the chain of arrows that still keeps it.
2. Detached nodes: type "Detached" in the snapshot's class filter box. Or choose the Detached elements profile type. Both list removed page elements that JavaScript still keeps.
3. Allocation instrumentation on timeline: this records new objects over time. Select a stretch of time to see which objects made then are still kept at the end.
4. Allocation sampling: this records less detail, so it slows the page down less. Use it for long sessions. It shows roughly which functions made the most objects.

Repeat the same open-and-close steps before you decide anything. Memory going up once can be normal: the page may be caching things, or clean-up may not have happened yet. Better signs of a leak are:

• the same kind of object keeps growing in number, and
• its retaining path goes through an old listener or cache.

The heap snapshots lesson covers retaining paths in detail.

// Works only in Chrome, and isn't part of the web standard.
console.log(performance.memory);

// Works only when the page is cross-origin isolated.
if (crossOriginIsolated && "measureUserAgentSpecificMemory" in performance) {
  const result = await performance.measureUserAgentSpecificMemory();
  console.log(result.bytes);
}

Common misconceptions

Each row has a wrong idea on the left and what is really true on the right.

Key takeaways

• JavaScript finds memory for objects as your code runs. Later, it cleans up the ones nothing can reach.
• Reachability starts at roots: global variables, running functions, and things the browser keeps, like listeners, timers, and the page itself.
• Mark and sweep cleans up objects that point at each other, as long as no root reaches them.
• Leaks usually come from things that live a long time: listeners, timers, closures, caches that only grow, and removed page elements you still keep.
• Use the Chrome DevTools Memory panel to look for leaks. Don't write code that depends on when clean-up happens.

Up next: WeakRef & FinalizationRegistry. There, the same warning matters most: you can't know when clean-up happens.