The V8 heap and object layout

The heap is not one pool — it’s several spaces

V8 does not treat the heap as one undifferentiated blob. It partitions it into spaces, each with its own allocation strategy and its own relationship to the garbage collector. The split is driven by the generational hypothesis: most objects die young, so it pays to allocate them somewhere cheap and disposable and only “promote” the rare survivors.

• New space (young generation) — small (a couple of MB up to tens of MB), where every normal object is born. It is split into two semi-spaces (from-space and to-space). Allocation here is the cheap path described below. New space is collected very frequently by a minor GC called the Scavenger.
• Old space (tenured) — large, where objects that survive a couple of Scavenges get promoted. Collected rarely, by the major GC (mark-compact). Long-lived data lives here.
• Large object space (LOS) — objects above a threshold (around 600 KB, roughly half a page-set) are allocated here directly and are never moved, because copying a huge object every GC would be wasteful. A big typed array or a giant string lands here.
• Code space — holds JIT-compiled machine code from Sparkplug/Maglev/TurboFan. Often paired with a dedicated code-range so generated code sits in a known region.
• Read-only space — immutable roots (the shared undefined Oddball, common Maps, internalised string roots). Being immutable, it can be shared across isolates, saving memory when you spawn many workers.

Together these spaces enforce one discipline: allocate cheap and temporary, pay later only if data survives. Without the separation, every allocation would need free-list management from birth, and every GC would have to handle code pages, immutable roots, and giant arrays the same way as ordinary short-lived objects — making both allocation and collection far more expensive.

(Historically there was also a separate Map space for hidden classes; later V8 folded it into old space.)

Bump-pointer allocation: why new is nearly free

Inside a semi-space, allocation is a bump-pointer. V8 keeps two values: a pointer to the next free byte (top) and the end of the space (limit). To allocate N bytes:

// Conceptual fast-path allocation in new space:
function allocate(bytes) {
  if (top + bytes > limit) return slowPath(bytes); // semi-space full -> trigger GC
  const addr = top;
  top += bytes;          // <-- the entire allocation: one pointer increment
  return addr;
}

That is it on the fast path: compare, then increment a pointer. No searching a free list, no coalescing, no size classes — the work malloc does. This is only possible because new space is collected by copying: when it fills, the live objects are moved out wholesale and the whole semi-space is reset to empty, so there is never fragmentation to manage.

When top would pass limit, the semi-space is full and V8 runs a Scavenge (minor GC): it copies the live objects from from-space into to-space (and promotes objects that have already survived once into old space), then swaps the roles of the two semi-spaces. Dead objects are not touched at all — they are simply left behind in the abandoned from-space, which makes collecting short-lived garbage essentially free. This is the deep reason “allocating lots of short-lived objects is cheap; keeping lots of objects alive is expensive.”

Object memory layout

Now zoom into a single plain object on the heap. Its layout, in order:

JS object in memory:
  [ Map pointer            ]  offset 0  — hidden class: kind + property layout
  [ properties backing-store ptr ]      — out-of-object named properties (overflow)
  [ elements backing-store ptr   ]      — indexed elements (the array part)
  [ in-object property slot 0    ]      — first fast property, stored inline
  [ in-object property slot 1    ]
  ...

• Map pointer (offset 0) — the hidden class, as we established two lessons ago: what kind of object this is and where each named property lives.
• Properties backing store — a pointer to an out-of-object array (or dictionary) holding properties that did not fit in the in-object slots.
• Elements backing store — a pointer to the indexed elements (obj[0], obj[1], …); arrays keep their numeric-keyed data here, separate from named properties.
• In-object property slots — the first several named properties are stored inline in the object’s own memory block (one memory load to read), the rest spill to the properties backing store (an extra dereference).

The number of in-object slots is fixed when the Map is created, which is why declaring your hot properties up front in a constructor keeps them in-object and fast. We go deep on hidden classes and in-object vs out-of-object properties in the hidden-classes unit; here, fix the skeleton: Map pointer, two backing-store pointers, then inline slots.