What triggers garbage collection in JavaScript?

GC in V8 (Chrome / Node) is generational mark-and-sweep with incremental and concurrent steps. JS doesn't expose a "free()" — the runtime decides when to collect, and what.

The generational model. Most objects die young. V8 splits the heap into:

• Young generation ("new space", ~1–8MB, small). Allocations happen here. Collected by the Scavenger — a copying collector that runs every few seconds under typical load. Survivors of two Scavenges get promoted.
• Old generation (large, MB to GB). Long-lived objects. Collected by Mark-Compact — slower, runs less often, can pause longer (mitigated by being mostly concurrent + incremental).

What triggers it.

1. Allocation pressure. When young space fills, a minor GC fires.
2. Heap-size thresholds. Old generation has soft limits; crossing them schedules a major GC.
3. Idle time hints. V8 prefers to run major GC during browser idle slots (between rAFs) to avoid jank.
4. Explicit pressure in Node — --expose-gc lets you call global.gc() (only for tests/benchmarks; not available to web pages).
5. OOM emergency. Under memory pressure, V8 will run an aggressive full GC.

JS apps can't trigger GC. They can only stop retaining things.

Reachability rules: an object is live if reachable from a GC root. Roots are: the global object, the current call stack, currently-executing closures, and platform-managed handles (timer callbacks, event listeners, microtask queue).

Common retainers (the actual interview content).

1. Closures holding large scopes.

``js function leaky() { const big = new Array(1e6); return () => 1; // returns a function that closes over big even if unused } ` V8 is good at trimming captured variables an inner function doesn't reference — but eval or with in scope inhibits the optimization, and some closures (e.g., debug` accessing all variables) defeat it. Capture only what you need.

1. Event listeners + DOM references. Attaching a listener with { once: false } and never removing it keeps both the handler and the DOM node alive. Especially bad: detached DOM trees referenced by a JS variable — they don't appear on screen but they're not collected.

1. Timers. setInterval/setTimeout callbacks are GC roots until they fire (or are clearIntervald).

1. Maps holding strong references. A Map<Element, Metadata> keeps the element alive even after it's removed from the DOM. Use WeakMap when the key is an object whose lifetime you don't own.

1. Global / module-scope caches. const cache = new Map() at module level lives forever.

1. Promise chains. A pending new Promise(resolve => ...) keeps resolve alive — if you never call it, you've leaked the closure.

WeakRef and FinalizationRegistry (2021+). WeakRef lets you hold a reference that doesn't prevent collection; FinalizationRegistry notifies you when an object was collected. Use for caches that should drain under pressure. Don't depend on finalizers running — they're best-effort, not guaranteed.

Detecting leaks.

• Performance → Memory tab in Chrome. "Heap snapshot" twice; compare retainer trees in the second one.
• Allocation timeline shows what code is allocating most.
• Node --inspect + Chrome DevTools for server-side heap snapshots.
• performance.memory.usedJSHeapSize — coarse-grained metric, fine for trend monitoring.

Why GC pauses cause jank. Before incremental GC, a major collection paused the main thread for 50–500ms = dropped frames. Modern V8 splits the work into small slices, interleaved with JS execution, and runs concurrent threads for marking. INP (Interaction to Next Paint) is partly a GC visibility metric — long INP often correlates with long GC pauses.

Senior framing. The right mental model: GC is reactive, not predictable. The only control you have is what you retain. Watch for closures, timers, listeners, Maps. Make caches WeakMap/WeakRef where lifetimes are externally owned. Profile with heap snapshots, don't speculate.