V8 generational GC and event loop responsiveness

WHY THIS MATTERS Memory behavior directly drives latency in Node, and this question separates engineers who understand the runtime from those who treat memory as invisible.

WHAT THIS TESTS Whether the candidate connects V8's heap layout and collection strategy to observable event loop stalls.

A GOOD ANSWER COVERS V8 uses a generational hypothesis: most objects die young. The heap has a small young generation (new space) collected by the Scavenger using a fast copying algorithm; these minor GCs run often but finish in well under a millisecond to a few milliseconds. Objects that survive several scavenges are promoted to the old generation, collected by a mark-sweep-compact major GC that is far less frequent but examines a much larger heap and takes longer. A stop-the-world pause means V8 suspends JavaScript execution to safely walk and move objects. Because the event loop runs on the same single thread, no callbacks, timers, or request handlers run during the pause, so a long major GC shows up as a latency spike across all in-flight work. V8 mitigates this with incremental marking and concurrent and parallel helper threads, but compaction and final marking still require short stop-the-world phases.

COMMON WRONG ANSWERS Claiming GC is entirely concurrent and never pauses JS. Confusing young and old generation costs. Ignoring that the pause blocks the loop because it shares the thread.

LIKELY FOLLOW-UPS How do you spot GC pauses in production? What causes excessive promotion to old space? How does --max-old-space-size relate? When would you reduce allocations or pool objects?

ONE CONCRETE EXAMPLE A service cached millions of objects, growing old space. Periodic major GCs caused p99 latency to jump by tens of milliseconds as the loop froze. Tracing GC with --trace-gc confirmed long mark-compact pauses; capping the cache and reducing long-lived allocations cut both pause duration and tail latency.