Generational GC in V8

The Generational Hypothesis

If you measured the lifetime of every object your JavaScript application creates, you'd discover something striking: the vast majority of objects die almost immediately after being created.

A temporary string from a template literal. An intermediate array from .map(). A short-lived options object passed to a function. An object destructured and never stored. These objects are created, used once, and become unreachable — often within the same function call.

This is the generational hypothesis: most objects die young, and the few that survive tend to live for a long time.

V8 exploits this observation by splitting the heap into two generations and using different GC strategies for each — optimizing for the common case of short-lived garbage.

Young Generation: The Nursery

All new objects (with exceptions for very large ones) are allocated in the Young Generation, also called New Space. In V8, New Space is typically 1-8 MB, split into two equal halves called semi-spaces:

• From-space — where objects currently live
• To-space — empty, waiting for the next collection

Only one semi-space is active at any time. New objects are allocated in the active semi-space using a bump allocator: just increment a pointer. This is nearly as fast as stack allocation — no free-list scanning, no fragmentation concerns.

The Scavenger Algorithm (Minor GC)

When the active semi-space fills up, V8 runs the Scavenger — a fast copying collector:

The genius of semi-space copying: the cost is proportional to the live objects, not the total heap size. If 90% of objects are dead (typical), the Scavenger only copies the surviving 10%. Dead objects are never even visited — their memory is reclaimed for free when the semi-space is wiped.

Promotion: From Young to Old

Objects that survive two Scavenger cycles are considered long-lived and get promoted (tenured) to the Old Generation. The logic is simple: if you survived two rounds of GC while most of your peers died, you're probably going to stick around.

// This object will likely be promoted
const appConfig = {
  apiUrl: '/api/v2',
  theme: 'dark',
  maxRetries: 3,
};
// appConfig is referenced globally, survives every GC cycle, gets promoted

// This object will never be promoted
function processItems(items) {
  const temp = items.map(item => ({ ...item, processed: true }));
  // temp becomes unreachable when processItems returns
  // Collected in the next Scavenger cycle — never promoted
  return temp.filter(t => t.valid);
}

Promotion Process

When the Scavenger finds a live object that has already survived one previous collection (tracked via an age bit), it copies that object to the Old Generation instead of To-space.

const longLived = {};  // promoted to Old Generation
// ... later ...
longLived.child = { temp: true };  // new object in Young Generation

Old Generation: Long-Term Storage

The Old Generation (Old Space) is much larger — typically hundreds of MB. Objects here have proven their longevity. They get collected by a different, more thorough algorithm: Mark-Sweep-Compact.

Mark Phase

Starting from roots, traverse all reachable objects and set their mark bit:

Roots → [global.app] → mark
  [global.app.state] → mark
    [global.app.state.users] → mark
      [User#1] → mark
      [User#2] → mark
    [global.app.state.cache] → mark
      ... and so on

Sweep Phase

Walk the entire Old Space linearly. Any object without a mark bit is freed, and its memory is added to a free list. Marked objects have their mark bits cleared (reset for the next cycle).

Compact Phase

Over time, sweeping leaves gaps (fragmentation) — freed objects leave holes between live objects. When fragmentation gets bad enough, V8 runs compaction: live objects are moved to eliminate gaps, producing contiguous free space.

Compaction is expensive (must update all references to moved objects) so V8 only compacts pages with the worst fragmentation, not the entire Old Space.

GC Frequency and Pause Times

The Young Generation is collected much more frequently but each collection is very fast (only copies survivors, and most objects are dead). The Old Generation is collected less often but each collection is more expensive (must traverse all live objects in a larger space).

Production Impact: Allocation Rate

The biggest factor in GC performance is your allocation rate — how many bytes per second your code allocates. Higher allocation rate means:

• Young Generation fills up faster → more frequent Scavenger runs
• More objects potentially promoted → larger Old Generation → more expensive major GCs
• More total GC time → less time for your application code

// HIGH allocation rate — creates garbage on every frame
function renderFrame(data) {
  const transformed = data.map(item => ({
    ...item,
    label: `${item.name}: ${item.value}`,
    style: { color: item.active ? 'green' : 'gray' }
  }));
  return transformed;
}
// Every call creates: 1 new array + N new objects + N new style objects + N new strings
// At 60fps, that's potentially thousands of objects per second

// LOW allocation rate — reuses objects
const styleCache = { active: { color: 'green' }, inactive: { color: 'gray' } };
const labelBuffer = [];

function renderFrame(data) {
  for (let i = 0; i < data.length; i++) {
    labelBuffer[i] = labelBuffer[i] || {};
    labelBuffer[i].name = data[i].name;
    labelBuffer[i].value = data[i].value;
    labelBuffer[i].style = data[i].active ? styleCache.active : styleCache.inactive;
  }
  labelBuffer.length = data.length;
  return labelBuffer;
}
// Reuses the same objects — minimal new allocations