Stack vs Heap — Where Variables Live
JavaScript allocates memory in two regions. Understanding which region holds which data is the foundation for reasoning about performance and leaks.
Memory Regions
Stack — fixed-size frames per function call; holds primitives and references
Heap — dynamic region; all objects, arrays, closures, and functions live here
Primitives (number, string, boolean, null, undefined, symbol, bigint) are value types copied on assignment
Objects and arrays are reference types — variables hold a pointer to the heap
Passing an object to a function copies the pointer, not the object itself
~KB
Stack frame size
Primitives, local vars, function frames
~1.5 GB
Heap object limit
V8 default 64-bit heap cap
~1–8 MB
Young gen size
Short-lived objects, collected frequently
~100s MB
Old gen size
Long-lived objects, major GC
iV8 Generational GC
V8 divides the heap into a small young generation (nursery) collected very frequently with a fast scavenger, and an old generation collected less often with mark-sweep-compact. Most objects die young — allocating short-lived objects is cheap.
V8 GC Lifecycle
1
Allocate
Object placed in young gen (nursery)
2
Minor GC
Scavenger copies survivors to semi-space
3
Promote
Objects surviving 2 minor GCs move to old gen
4
Major GC
Mark-sweep-compact frees old gen unreachables
5
Compaction
Live objects moved together to reduce fragmentation
What Keeps Objects Alive — The Retain Graph
The garbage collector starts from a set of GC roots (global object, active call stack, V8 internals) and marks every object reachable by following references. Anything not marked is unreachable and can be freed. An object is kept alive by a single live reference anywhere in the graph.
GC Roots
Global (window), active stack frames, V8 internal handles
Reachable
Object is directly or transitively referenced from a root
Unreachable
No path from any root → eligible for collection
Retain path
Chain of references that keeps an object alive — shown in DevTools Retainers panel
Reachability example
// Object is reachable → NOT collected
const cache = new Map();
function store(key, value) {
cache.set(key, value); // cache lives as long as the module
}
// Object is unreachable → eligible for GC
function example() {
const temp = { data: new ArrayBuffer(1_000_000) };
// temp goes out of scope here → GC can reclaim it
}Cyclic references are fine
A→B→A cycle is still collected if neither A nor B is reachable from a root. Mark-sweep handles cycles correctly — reference counting (the old approach) could not.
Common Memory Leak Patterns
Leaks in JavaScript are almost always caused by unintentional long-lived references — the GC cannot collect something you are still holding onto. The five patterns below account for the vast majority of real-world leaks.
Listener leak + fix
// ❌ Leak: listener never removed
function attachHandler(element) {
element.addEventListener("click", handleClick);
// handleClick holds a closure over outer variables
// element stays alive as long as handleClick is referenced
}
// ✅ Fix: always remove listeners when no longer needed
function attachHandler(element) {
const controller = new AbortController();
element.addEventListener("click", handleClick, {
signal: controller.signal,
});
return () => controller.abort(); // call this to clean up
}
// ✅ React fix: cleanup in useEffect return
useEffect(() => {
window.addEventListener("resize", onResize);
return () => window.removeEventListener("resize", onResize);
}, []);WeakMap, WeakSet, WeakRef, FinalizationRegistry
ES2015+ added weak collection types that hold references without preventing garbage collection. They are ideal for metadata stores and caches where the lifetime of the value should follow the lifetime of the key object.
| Map | WeakMap |
|---|---|
| Keys can be any value | Keys must be objects or non-registered symbols |
| Strongly holds keys | Weakly holds keys — GC can collect them |
| Iterable (forEach, for…of) | Not iterable — no size, no forEach |
| Has .size property | No .size — count unknown at runtime |
| Use for general caches | Use for object-keyed metadata, private data |
WeakMap, WeakRef, FinalizationRegistry
// WeakMap — keys are weakly held; entry removed when key is GC'd
const metadata = new WeakMap();
class Component {
constructor() {
metadata.set(this, { createdAt: Date.now() });
}
// When this instance is collected, metadata entry is removed automatically
}
// WeakRef — hold a reference that doesn't prevent GC
const ref = new WeakRef(largeObject);
const deref = ref.deref(); // undefined if already collected
if (deref) {
deref.doWork();
}
// FinalizationRegistry — callback when target is collected
const registry = new FinalizationRegistry((heldValue) => {
console.log("Collected:", heldValue);
});
registry.register(target, "my-target");✓WeakRef gotcha
WeakRef.deref() can return undefined at any point — even between two lines of code if a GC cycle runs. Always guard with if (deref) before using the result.
Heap Snapshots in DevTools
Chrome DevTools Memory panel lets you take heap snapshots and compare them to find retained objects. This is the primary tool for diagnosing suspected memory leaks.
1
Open DevTools Memory panel
Chrome: F12 → Memory tab. Select 'Heap snapshot' and click 'Take snapshot'.
2
Reproduce the leak
Perform the action you suspect causes the leak (navigate, click, run feature).
3
Take a second snapshot
Click 'Take snapshot' again. You now have a baseline and a post-action snapshot.
4
Switch to Comparison view
In the dropdown change 'Summary' to 'Comparison'. Objects added or removed between snapshots appear here.
5
Filter by #Delta
Sort by '# Delta' (count change). Growing object types with positive delta are suspects.
6
Inspect retainers
Click a suspicious object → expand the 'Retainers' tree to trace what is keeping it alive.
Shallow size
Memory held directly by the object itself
Retained size
Total memory freed if this object were collected (includes its subgraph)
Detached nodes
DOM elements removed from the tree but kept alive by JS — filter by 'Detached' in the class filter
Retainers panel
Shows the shortest path from a GC root to the selected object — the retain chain you need to cut
Allocation Timeline — Spotting the Leak Shape
The Allocation instrumentation timeline records every allocation over time. The shape of the heap graph tells you immediately whether a leak is present.
Heap Growth Patterns
Healthy (sawtooth)30 MB
Leaking (staircase)85 MB
After fix (stable)32 MB
Staircase pattern = confirmed leak
If heap usage rises after each action and the GC never brings it back to baseline, objects are being retained across GC cycles. Take snapshots before and after the suspected action and compare.
Heap growth
Leaking page
↑ 8 MB / min
Heap climbs without plateau
After cleanup
~stable
GC restores baseline after each action
85%
Heap pressure (leaking)
28%
Heap pressure (fixed)
React-Specific Memory Patterns
React components mount and unmount frequently. Any subscription, timer, or network request started in useEffect must be cancelled in the cleanup function, otherwise it outlives the component and leaks.
React useEffect cleanup patterns
// ✅ AbortController for fetch — cancels inflight request on unmount
useEffect(() => {
const controller = new AbortController();
fetch("/api/data", { signal: controller.signal })
.then((res) => res.json())
.then(setData)
.catch((err) => {
if (err.name !== "AbortError") setError(err);
});
return () => controller.abort();
}, []);
// ✅ Clear timer on unmount
useEffect(() => {
const id = setTimeout(() => setVisible(false), 3000);
return () => clearTimeout(id);
}, []);
// ✅ Remove event listener on unmount
useEffect(() => {
const handler = (e) => setKey(e.key);
window.addEventListener("keydown", handler);
return () => window.removeEventListener("keydown", handler);
}, []);Required
useEffect cleanup
Return a cleanup fn for any subscription, timer, or listener
Preferred
AbortController
Cancel fetch requests on unmount to avoid setState on unmounted component
Profiler
React DevTools
Use Profiler to spot components that never unmount when expected
Memory Leak Audit Checklist0/9