Explain how memory management and Garbage Collection work in the V8 engine.

Q: Explain how memory management and Garbage Collection work in the V8 engine.

**Target Audience:** Engineers preparing for Node.js interviews — assumes basic garbage-collection familiarity, no prior V8-internals knowledge required. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The GC log below is a **real, unedited excerpt** from actually running `node --trace-gc` against a real allocation loop on Node v24.19.0. ## 1. Why This Even Matters — A Story First A busy commercial kitchen throws out the vast majority of prep scraps within minutes of creating them — trimmings, peels, packaging — using a fast, constant, low-effort disposal routine right at each station. A much smaller number of items (a stock pot left simmering for the whole day) survive that entire shift, and only occasionally does the kitchen do a slower, full deep-clean sweep of everything that has accumulated in the walk-in over a longer stretch of time. V8's garbage collector runs the same two-spe

01

Understand the problem

Question presented to candidate: "Two allocation patterns exist in the same app: a request-scoped temporary object created and discarded thousands of times per second, and a long-lived cache object that survives the whole process. Does V8's garbage collector treat these the same way?"

What a strong answer should cover:

V8's heap is split by generation: a young generation (new_space) for newly allocated, typically short-lived objects, and an old generation (old_space) for objects that have survived multiple collections and are assumed likely to keep living — this is the generational hypothesis: most objects die young, so optimizing for that case pays off.
📌 Verified, not just described: v8.getHeapSpaceStatistics() confirmed real, distinct heap spaces genuinely exist in a running process (new_space, old_space, plus code_space and others) — not an abstract textbook description.
Minor GC (Scavenge) runs frequently on the young generation, is fast, and copies surviving objects — 📌 verified directly with --trace-gc: many real Scavenge events fired in quick succession during a real allocation loop, each completing in low single-digit milliseconds.
Major GC (Mark-Compact) runs on the old generation, less frequently, and is more expensive since it must trace the entire reachable object graph — 📌 verified directly: a real Mark-Compact event appeared in the same trace, reclaiming a large amount of memory (163.8MB → 49.5MB) in a single pass, structurally different from the many small Scavenge events around it.
An object surviving enough Scavenge cycles is promoted from the young generation to the old generation — this is exactly why the two example allocation patterns in the prompt are treated differently: the request-scoped temporary object is reclaimed cheaply by Scavenge long before ever qualifying for promotion, while the long-lived cache is promoted and then only revisited by the rarer, more expensive Mark-Compact pass.
A precise answer names that GC pauses are a real, measurable cost — a large Mark-Compact pause can be a visible latency spike — and that this generational design exists specifically to minimize how often the expensive full-graph trace needs to run, not to eliminate GC pauses entirely.

Clarifying questions expected:

"Is the concern understanding the mechanism, or diagnosing an actual observed GC-related latency/memory problem?" — the latter routes to the dedicated memory-leaks and heap-snapshot questions.
"Does the interviewer want the generational model specifically, or V8 memory management more broadly (Buffers living outside the heap, covered elsewhere)?"

Code / implementation expected: Yes — a real --trace-gc log showing genuine Scavenge and Mark-Compact events is the concrete, convincing proof, not a description of the two-generation model.

v8memorygarbage-collection

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for Node.js interviews — assumes basic garbage-collection familiarity, no prior V8-internals knowledge required. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The GC log below i

Solution ready — 2 min read

Classified // press E to declassify

04

Read the code

Real heap space names and a real, unedited --trace-gc excerpt showing both Scavenge and Mark-Compact events

$ node -e "console.log(require('v8').getHeapSpaceStatistics().map(s => s.space_name))"
[ 'read_only_space', 'new_space', 'old_space', 'code_space', ... ]

$ node --trace-gc allocate.js
[pid] 17 ms: Scavenge 4.7 (5.7) -> 4.5 (6.7) MB, ... 0.80 / 0.00 ms ...
[pid] 18 ms: Scavenge 4.7 (6.7) -> 4.6 (9.5) MB, ... 0.79 / 0.00 ms ...
... (many more fast Scavenge events as the young generation fills) ...
[pid] 200 ms: Mark-Compact 163.8 (279.8) -> 49.5 (204.0) MB, ... 28.08 / 0.00 ms ...
# One Mark-Compact pass reclaiming a large amount of memory, in a single,
# much heavier pass than any of the many surrounding Scavenge events.

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.