JavaScript Memory and Garbage Collection

Function calls and their local variables live on the stack, which is freed automatically when a function returns. Objects, arrays, strings and closures live on the heap, and that's the part the garbage collector manages. Small integers can be stored directly, but a variable holding an object only holds a reference to it.

When nothing reachable points to it any more. Setting a variable to null only removes one reference: if anything else still points to the object, it stays alive. And garbage isn't freed straight away. Its memory is reclaimed the next time the collector runs, which the engine decides.

It starts at the roots (global variables, the locals of running functions, and what the browser holds, like DOM nodes and timers) and marks everything it can reach. Whatever it can't reach is garbage. Circular references aren't a problem: two objects pointing at each other are still unreachable if no root leads to them. Reference counting couldn't free them, which is why engines trace from the roots instead.

Most objects die young, so V8 puts new objects in a small young generation and collects it often. A minor GC, the Scavenger, copies only the objects that are still reachable into a fresh space, so its cost depends on what survives, not on how much was allocated. Objects that survive two minor GCs are promoted to the old generation.

In three steps. Mark walks from the roots and marks everything reachable. Sweep frees whatever wasn't marked and adds the space to a free list. Over time that leaves holes too small to use, so compaction moves the live objects out of the most fragmented pages and updates every pointer to them. Moving objects is expensive, so V8 only compacts the pages that need it.

Partly. A stop-the-world pause grows with the heap and can drop frames, since a frame at 60 fps has about 16 ms. So V8 avoids it: minor GCs pause briefly but split the work across threads, old-generation marking runs incrementally and concurrently on helper threads, and sweeping happens in the background. Compaction is the part that still needs a short pause.

The garbage collector only checks whether an object is reachable, not whether you still need it. So a leak is a reference you forgot to remove. The usual suspects are event listeners that never unsubscribe, timers that are never cleared, values left on window, detached DOM nodes your code still holds, and caches with no size limit or expiry. The fix is to break the reference: unsubscribe, clear the timer, delete the entry, or cap the cache.

A WeakMap holds its keys weakly: an entry doesn't keep its key alive, and when the key is collected the entry goes with it. It's the right tool for attaching data to objects you don't own, like DOM nodes, without having to remember to clean up. The trade-off is that keys must be objects or non-registered symbols, and you can't loop over it or read its size, because entries can disappear at any time.

First confirm it: memory that keeps growing after each GC as you repeat an action. Then, in Chrome's Memory panel, take a heap snapshot, repeat the action a few times and take another. The Comparison view shows what grew. Retained size tells you what's worth fixing, and the retainers show the path back to your code. Break that reference, then run the same test to confirm the fix.