Docs
24.3-Garbage-Collection-Advanced
22.3 Advanced Garbage Collection
Understanding V8's garbage collection helps you write memory-efficient code and avoid performance issues. This section covers the internals of V8's generational and incremental GC.
Table of Contents
- •22.3 Advanced Garbage Collection
Garbage Collection Fundamentals
JavaScript automatically manages memory. The garbage collector finds and frees unused objects.
┌─────────────────────────────────────────────────────────────────────┐
│ MEMORY LIFECYCLE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. ALLOCATION │
│ const obj = { x: 1, y: 2 }; │
│ const arr = [1, 2, 3, 4, 5]; │
│ │
│ 2. USE │
│ console.log(obj.x); │
│ arr.forEach(n => process(n)); │
│ │
│ 3. COLLECTION (Automatic) │
│ // When obj and arr are no longer reachable │
│ // GC reclaims the memory │
│ │
│ The Challenge: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • Must find ALL unreachable objects │ │
│ │ • Must not free objects still in use │ │
│ │ • Should minimize pause times │ │
│ │ • Should be memory efficient │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Reachability
┌─────────────────────────────────────────────────────────────────────┐
│ REACHABILITY CONCEPT │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ROOT OBJECTS (Always Reachable): │
│ • Global object (window/global) │
│ • Currently executing functions (call stack) │
│ • Active closures │
│ │
│ Reachability Chain: │
│ │
│ ┌────────┐ │
│ │ Roots │ │
│ └────┬───┘ │
│ │ │
│ ┌────▼───┐ ┌────────┐ ┌────────┐ │
│ │ Obj A │────→│ Obj B │────→│ Obj C │ ← REACHABLE │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ ┌────────┐ ┌────────┐ │
│ │ Obj X │────→│ Obj Y │ ← UNREACHABLE (no path from roots) │
│ └────────┘ └────────┘ │
│ │
│ Example: │
│ let user = { name: "Alice" }; // Reachable via 'user' │
│ user = null; // Now unreachable - GC can free │
│ │
└─────────────────────────────────────────────────────────────────────┘
V8 Memory Structure
V8 divides the heap into different spaces for efficient memory management.
┌─────────────────────────────────────────────────────────────────────┐
│ V8 HEAP STRUCTURE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HEAP │ │
│ │ ┌─────────────────────────────────────────────────────────┐│ │
│ │ │ NEW SPACE (Young Generation) ││ │
│ │ │ ┌──────────────────┐ ┌──────────────────┐ ││ │
│ │ │ │ From-Space │ │ To-Space │ ││ │
│ │ │ │ (Active) │ │ (Empty) │ ││ │
│ │ │ │ 1-8 MB each │ │ │ ││ │
│ │ │ └──────────────────┘ └──────────────────┘ ││ │
│ │ └─────────────────────────────────────────────────────────┘│ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────┐│ │
│ │ │ OLD SPACE (Old Generation) ││ │
│ │ │ ││ │
│ │ │ • Objects that survived young generation ││ │
│ │ │ • Large objects (allocated directly here) ││ │
│ │ │ • Size: Grows dynamically (up to heap limit) ││ │
│ │ │ ││ │
│ │ └─────────────────────────────────────────────────────────┘│ │
│ │ │ │
│ │ ┌───────────────────┐ ┌───────────────────┐ │ │
│ │ │ Code Space │ │ Map Space │ │ │
│ │ │ (Compiled code) │ │ (Hidden classes) │ │ │
│ │ └───────────────────┘ └───────────────────┘ │ │
│ │ │ │
│ │ ┌───────────────────┐ │ │
│ │ │ Large Object Space│ │ │
│ │ │ (Objects > 1MB) │ │ │
│ │ └───────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Memory Spaces Explained
| Space | Purpose | GC Type | Size |
|---|---|---|---|
| New Space | New objects | Minor GC (Scavenger) | 1-8 MB per semi-space |
| Old Space | Long-lived objects | Major GC (Mark-Sweep) | Dynamic |
| Code Space | JIT compiled code | Rarely collected | Dynamic |
| Map Space | Hidden classes | Collected with old space | Dynamic |
| Large Object Space | Objects > 1MB | Major GC | Dynamic |
Generational Garbage Collection
V8 uses the "generational hypothesis": most objects die young.
┌─────────────────────────────────────────────────────────────────────┐
│ GENERATIONAL HYPOTHESIS │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Object Lifetime Distribution: │
│ │
│ Objects │ │
│ Created │█████████████████████ │
│ │██████████████ │
│ │████████ │
│ │█████ │
│ │███ │
│ │██ │
│ │█ │
│ │█ │
│ │█ │
│ └────────────────────────────────────────────────────── │
│ Short Medium Long Object Lifespan │
│ │
│ Key Insight: │
│ • Most objects (80-90%) die very young │
│ • Few objects live for a long time │
│ • Optimize for the common case (short-lived objects) │
│ │
│ Strategy: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ YOUNG GENERATION OLD GENERATION │ │
│ │ • Small, fast GC • Large, slower GC │ │
│ │ • Runs frequently • Runs less often │ │
│ │ • Scavenge algorithm • Mark-Sweep-Compact │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Scavenger (Minor GC)
The Scavenger handles the young generation using a copying algorithm.
┌─────────────────────────────────────────────────────────────────────┐
│ SCAVENGE ALGORITHM │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ BEFORE SCAVENGE: │
│ ┌────────────────────────┐ ┌────────────────────────┐ │
│ │ From-Space │ │ To-Space │ │
│ │ ┌───┐┌───┐┌───┐┌───┐ │ │ (Empty) │ │
│ │ │ A ││ B ││ C ││ D │ │ │ │ │
│ │ └───┘└───┘└───┘└───┘ │ │ │ │
│ │ ┌───┐┌───┐ │ │ │ │
│ │ │ E ││ F │ │ │ │ │
│ │ └───┘└───┘ │ │ │ │
│ └────────────────────────┘ └────────────────────────┘ │
│ │
│ Assume: A, C, E are reachable; B, D, F are garbage │
│ │
│ AFTER SCAVENGE: │
│ ┌────────────────────────┐ ┌────────────────────────┐ │
│ │ From-Space │ │ To-Space │ │
│ │ (Empty) │ │ ┌───┐┌───┐┌───┐ │ │
│ │ │ │ │ A ││ C ││ E │ │ │
│ │ │ │ └───┘└───┘└───┘ │ │
│ │ │ │ │ │
│ │ │ │ Survivors copied │ │
│ │ │ │ Compacted together │ │
│ └────────────────────────┘ └────────────────────────┘ │
│ │
│ Then: Spaces are SWAPPED │
│ • To-Space becomes new From-Space │
│ • Old From-Space becomes new To-Space │
│ │
└─────────────────────────────────────────────────────────────────────┘
Object Promotion
┌─────────────────────────────────────────────────────────────────────┐
│ OBJECT PROMOTION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Objects are PROMOTED to Old Space when: │
│ │
│ 1. They survive TWO scavenges │
│ 2. To-Space is more than 25% full │
│ │
│ First Scavenge: │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ From-Space │ │ To-Space │ │
│ │ ┌───┐ │ ──→ │ ┌───┐ │ │
│ │ │ A │ │ copy │ │ A │ │ A survives (age = 1) │
│ │ └───┘ │ │ └───┘ │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Second Scavenge: │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ From-Space │ │ To-Space │ │ Old Space │ │
│ │ ┌───┐ │ │ │ │ ┌───┐ │ │
│ │ │ A │ │ ──────────────────────→ │ │ A │ │ PROMOTED│
│ │ └───┘ │ │ └───┘ │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Promotion Benefits: │
│ • Long-lived objects don't get copied repeatedly │
│ • Young GC stays fast (fewer objects to scan) │
│ │
└─────────────────────────────────────────────────────────────────────┘
Scavenger Characteristics
| Aspect | Details |
|---|---|
| Algorithm | Cheney's copying algorithm |
| Speed | Very fast (1-2ms typical) |
| Frequency | Often (when new space fills) |
| Stop-the-world | Yes, but very short pause |
| Memory overhead | 2x (two semi-spaces) |
| Fragmentation | None (compacting by nature) |
Mark-Sweep-Compact (Major GC)
Major GC handles the old generation using mark-sweep-compact algorithm.
┌─────────────────────────────────────────────────────────────────────┐
│ MARK-SWEEP-COMPACT │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ PHASE 1: MARK │
│ ─────────────── │
│ Start from roots, mark all reachable objects │
│ │
│ Roots │
│ │ │
│ ▼ │
│ ┌───┐ ┌───┐ ┌───┐ │
│ │ A │────→│ B │────→│ C │ ← Marked (reachable) │
│ └───┘ └───┘ └───┘ │
│ ● ● ● │
│ │
│ ┌───┐ ┌───┐ │
│ │ X │ │ Y │ ← Not marked (garbage) │
│ └───┘ └───┘ │
│ │
│ PHASE 2: SWEEP │
│ ──────────────── │
│ Free memory of unmarked objects │
│ │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │ A │ │ B │ │ │ │ C │ │ │ │
│ └───┘ └───┘ └───┘ └───┘ └───┘ │
│ ● ● FREE ● FREE │
│ │
│ PHASE 3: COMPACT (Optional) │
│ ────────────────────────── │
│ Move objects to eliminate fragmentation │
│ │
│ BEFORE: │ A │ │ B │ │ C │ │ │
│ AFTER: │ A │ B │ C │ │ FREE │
│ │
└─────────────────────────────────────────────────────────────────────┘
Tri-Color Marking
┌─────────────────────────────────────────────────────────────────────┐
│ TRI-COLOR MARKING │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Three Colors: │
│ • WHITE: Not yet visited (potentially garbage) │
│ • GRAY: Visited, but children not scanned │
│ • BLACK: Visited and all children scanned │
│ │
│ Algorithm: │
│ │
│ 1. Initially all objects are WHITE │
│ 2. Roots are marked GRAY │
│ 3. While GRAY objects exist: │
│ a. Pick a GRAY object │
│ b. Mark its WHITE children GRAY │
│ c. Mark the object BLACK │
│ 4. All WHITE objects are garbage │
│ │
│ Visual: │
│ │
│ Step 1: ○──○──○──○ (all white) │
│ │ │
│ Root │
│ │
│ Step 2: ◐──○──○──○ (root is gray) │
│ │
│ Step 3: ●──◐──○──○ (root black, child gray) │
│ │
│ Step 4: ●──●──◐──○ (continue marking) │
│ │
│ Step 5: ●──●──●──○ (one object remains white = garbage) │
│ │
│ Legend: ○ = WHITE, ◐ = GRAY, ● = BLACK │
│ │
└─────────────────────────────────────────────────────────────────────┘
Incremental and Concurrent GC
V8 uses various techniques to reduce pause times.
┌─────────────────────────────────────────────────────────────────────┐
│ PAUSE TIME STRATEGIES │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ STOP-THE-WORLD (Blocking) │
│ ───────────────────────── │
│ JavaScript ████████████████░░░░░░░░░░░████████████████ │
│ GC ████████████ │
│ │← Pause →│ │
│ │
│ Problem: Long pauses (100ms+) cause jank │
│ │
│ INCREMENTAL MARKING │
│ ────────────────── │
│ JavaScript ████░████░████░████░████░████░████████████ │
│ GC ░ ░ ░ ░ ░ ░ │
│ │ Small increments │ │
│ │
│ Mark in small chunks interleaved with JavaScript │
│ │
│ CONCURRENT MARKING │
│ ───────────────── │
│ JavaScript ██████████████████████████████████████████ │
│ GC (thread) ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │
│ │←── Marking in parallel ──→│ │
│ │
│ Mark on a separate thread while JavaScript runs │
│ │
│ PARALLEL SCAVENGING │
│ ────────────────── │
│ JavaScript ████████████████░░░████████████████████████ │
│ GC Thread 1 ░░░ │
│ GC Thread 2 ░░░ │
│ GC Thread 3 ░░░ │
│ │← Short pause, parallel work │ │
│ │
└─────────────────────────────────────────────────────────────────────┘
V8's Orinoco GC
V8's modern garbage collector (Orinoco) combines multiple techniques:
┌─────────────────────────────────────────────────────────────────────┐
│ ORINOCO GC FEATURES │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. PARALLEL SCAVENGING │
│ • Multiple threads evacuate young generation │
│ • Reduces minor GC pause time │
│ │
│ 2. CONCURRENT MARKING │
│ • Marking happens on background threads │
│ • Main thread continues executing JavaScript │
│ • Only short atomic pause for finalization │
│ │
│ 3. INCREMENTAL MARKING │
│ • Mark objects in small steps │
│ • Interleaved with JavaScript execution │
│ • Write barriers track mutations │
│ │
│ 4. LAZY SWEEPING │
│ • Sweep pages lazily as memory is needed │
│ • Spread sweeping work over time │
│ │
│ 5. CONCURRENT COMPACTION │
│ • Move objects on background thread │
│ • Update pointers incrementally │
│ │
│ Timeline Example: │
│ │
│ Main Thread ████████░██████████████░███████████████████ │
│ Worker 1 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │
│ Worker 2 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │
│ └── Concurrent marking ──┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Memory Leaks and Detection
Common patterns that cause memory leaks in JavaScript.
┌─────────────────────────────────────────────────────────────────────┐
│ COMMON MEMORY LEAKS │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. FORGOTTEN EVENT LISTENERS │
│ │
│ element.addEventListener('click', handler); │
│ // Later: element removed, but handler still referenced │
│ // Fix: element.removeEventListener('click', handler); │
│ │
│ 2. DETACHED DOM NODES │
│ │
│ const nodes = []; │
│ function onClick() { │
│ const div = document.createElement('div'); │
│ nodes.push(div); // div is retained even if removed │
│ } │
│ │
│ 3. CLOSURES OVER LARGE SCOPES │
│ │
│ function process() { │
│ const hugeData = loadHugeData(); │
│ return function() { │
│ // Closure keeps hugeData alive! │
│ return doSomething(); │
│ }; │
│ } │
│ │
│ 4. GROWING CACHES │
│ │
│ const cache = {}; │
│ function getData(key) { │
│ if (!cache[key]) { │
│ cache[key] = fetchData(key); // Never cleaned up! │
│ } │
│ return cache[key]; │
│ } │
│ │
│ 5. CIRCULAR REFERENCES (Historical - modern GCs handle this) │
│ │
│ const a = {}; │
│ const b = {}; │
│ a.ref = b; │
│ b.ref = a; // Not a leak in modern V8 │
│ │
└─────────────────────────────────────────────────────────────────────┘
Detecting Memory Leaks
┌─────────────────────────────────────────────────────────────────────┐
│ LEAK DETECTION STRATEGIES │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. CHROME DEVTOOLS HEAP SNAPSHOTS │
│ │
│ Take multiple snapshots → Compare → Find growing objects │
│ │
│ Snapshot 1: 10 MB │
│ Snapshot 2: 15 MB (+5 MB - investigate!) │
│ Snapshot 3: 20 MB (+5 MB - likely leak!) │
│ │
│ 2. ALLOCATION TIMELINE │
│ │
│ Record allocations over time │
│ Blue bars = allocated, Gray = freed │
│ Growing blue = leak │
│ │
│ ████░░░████░░░████░░░████░░░████░░░ │
│ Normal: allocate, then freed │
│ │
│ ████░░░████████░░░████████████░░░████████████████ │
│ Leak: allocations not freed │
│ │
│ 3. NODE.JS FLAGS │
│ │
│ node --expose-gc --trace-gc script.js │
│ process.memoryUsage() │
│ │
│ 4. PERFORMANCE.MEMORY (Chrome) │
│ │
│ console.log(performance.memory.usedJSHeapSize); │
│ // Monitor over time │
│ │
└─────────────────────────────────────────────────────────────────────┘
Optimization Strategies
Strategy 1: Object Pooling
// Instead of creating many short-lived objects:
// BAD
function process(data) {
return { x: data.x * 2, y: data.y * 2 }; // New object each time
}
// GOOD: Reuse objects from a pool
class VectorPool {
constructor(size = 100) {
this.pool = Array.from({ length: size }, () => ({ x: 0, y: 0 }));
this.index = 0;
}
acquire(x, y) {
const obj = this.pool[this.index];
this.index = (this.index + 1) % this.pool.length;
obj.x = x;
obj.y = y;
return obj;
}
}
Strategy 2: Avoid Closures Over Large Data
// BAD: Closure retains large data
function createProcessor(hugeData) {
return function process(index) {
return hugeData[index]; // hugeData never freed
};
}
// GOOD: Only capture what's needed
function createProcessor(hugeData) {
const lookup = new Map(); // Extract needed data
hugeData.forEach((item, i) => lookup.set(i, item.value));
return function process(index) {
return lookup.get(index);
};
}
Strategy 3: Bounded Caches
// BAD: Unbounded cache
const cache = {};
// GOOD: Use LRU cache with limit
class LRUCache {
constructor(maxSize = 100) {
this.maxSize = maxSize;
this.cache = new Map();
}
get(key) {
if (this.cache.has(key)) {
const value = this.cache.get(key);
this.cache.delete(key);
this.cache.set(key, value); // Move to end
return value;
}
return undefined;
}
set(key, value) {
if (this.cache.has(key)) {
this.cache.delete(key);
} else if (this.cache.size >= this.maxSize) {
const firstKey = this.cache.keys().next().value;
this.cache.delete(firstKey); // Remove oldest
}
this.cache.set(key, value);
}
}
Strategy 4: WeakMap for Object Metadata
// BAD: Strong reference prevents GC
const metadata = new Map();
function setMeta(obj, data) {
metadata.set(obj, data); // obj can't be GC'd!
}
// GOOD: WeakMap allows GC
const metadata = new WeakMap();
function setMeta(obj, data) {
metadata.set(obj, data); // obj can be GC'd
}
Key Takeaways
┌─────────────────────────────────────────────────────────────────────┐
│ GC SUMMARY │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ GENERATIONAL GC: │
│ • Young generation: Small, fast, frequent GC (Scavenger) │
│ • Old generation: Large, slower, less frequent GC (Mark-Sweep) │
│ • Objects promoted after surviving 2 scavenges │
│ │
│ MODERN V8 (ORINOCO): │
│ • Parallel: Multiple GC threads │
│ • Concurrent: GC runs alongside JavaScript │
│ • Incremental: Work spread over time │
│ • Result: Minimal pause times │
│ │
│ AVOID MEMORY LEAKS: │
│ ✅ Remove event listeners when done │
│ ✅ Clear references to detached DOM nodes │
│ ✅ Avoid closures over large data │
│ ✅ Use bounded caches (LRU) │
│ ✅ Use WeakMap/WeakSet for object metadata │
│ │
│ OPTIMIZE ALLOCATIONS: │
│ ✅ Reuse objects (object pooling) │
│ ✅ Avoid creating objects in hot loops │
│ ✅ Pre-allocate arrays when size is known │
│ ✅ Prefer primitives over objects when possible │
│ │
└─────────────────────────────────────────────────────────────────────┘
Next Steps
Continue to 22.4 ES Modules Internals to understand how JavaScript modules are loaded, parsed, and executed.