V8 optimization: hidden classes, inline caches, and the JIT tiers

Hidden classes: objects are typed even though JavaScript isn’t

JavaScript has no static types, but V8 invents them at runtime. Every object points to a hidden class (V8 calls it a Map, also documented as a Shape) that records the object’s layout: which properties exist, in what order, and at which memory offset each one lives. Two objects created the same way — same properties added in the same order — share the same hidden class, so V8 can compile a property access into “read the slot at offset 16” instead of a hash-map lookup.

Hidden classes are built by transitions. Start with {} (the empty hidden class C0); add x and you transition to C1; add y and you transition to C2. V8 caches these transitions in a tree, so the next object that adds x then y walks the same path and lands on the same C2 — no new class allocated. This is why object construction order is load-bearing.

function makePoint(a, b) {
  const p = {};
  p.x = a;   // C0 -> C1
  p.y = b;   // C1 -> C2
  return p;
}
// Both share hidden class C2 — V8 treats them as one "type":
const p1 = makePoint(1, 2);
const p2 = makePoint(3, 4);

// But add the SAME properties in a different ORDER and you get a
// different transition path — a SECOND hidden class for the same fields:
const q = {};
q.y = 2;   // C0 -> C1'
q.x = 1;   // C1' -> C2'   (C2' != C2)

Three things break shape sharing and you must know all three:

• Adding properties in a different order produces a divergent transition path and a distinct hidden class, even though the field set is identical.
• delete obj.prop is the worst: V8 cannot represent a “hole” in a fast packed layout, so it converts the object to dictionary mode (slow properties) — a hash map per object, with no shared hidden class and no inline-cache benefit. Use obj.prop = undefined or rebuild the object if you truly need the key gone.
• Mixing value types in the same slot (an integer where a double or object usually lives) changes the field’s representation and forces a hidden-class change; for arrays it triggers an elements-kind transition (PACKED_SMI → PACKED_DOUBLE → PACKED_ELEMENTS, each strictly more general and less optimisable).

Together these three shape-breakers push an object off the fast path permanently — once in dictionary mode, there is no automatic recovery. Miss any one of them on a hot object and you pay the hash-map tax on every property read in that function.

Inline caches: monomorphic, polymorphic, megamorphic

A hidden class is only half the machinery. The other half is the inline cache (IC): at each property-access site — obj.x in some function — V8 remembers which hidden class it saw and the offset it resolved to. Next time, if the object has the same hidden class, it reads the cached offset directly. The IC’s state is the single best predictor of how fast that site runs.

function dist(p) {
  return Math.sqrt(p.x * p.x + p.y * p.y); // the IC lives at p.x / p.y
}

• Monomorphic — the site has only ever seen one hidden class. The IC is a single compare-and-read; this is the fast path and the one TurboFan can inline and speculate on hardest.
• Polymorphic — the site has seen 2–4 hidden classes. V8 keeps a small list and linearly checks each; slower, but still optimisable.
• Megamorphic — more than ~4 shapes. V8 gives up on the per-site cache and falls back to a generic megamorphic stub (a global hash lookup). This is the cliff: it is dramatically slower and blocks the function from being well-optimised.

The practical rule: feed each hot call site objects of one shape. A function that normalises three different payload shapes should be three monomorphic functions (or normalise to one shape before the hot path), not one megamorphic one.

JIT tiers: Ignition, Sparkplug, Maglev, TurboFan

V8 does not compile your code to optimised machine code up front — that would waste compile time on code that runs once. Instead it tiers up based on how hot a function is, trading compile speed for code quality at each step.

TurboFan’s speed comes from speculation: it assumes p is always shape C2 and bakes that assumption into the code, dropping all the type checks. When the assumption holds, it flies. When it breaks — a C3 object shows up, a slot’s type changes — the speculation is invalid and V8 deoptimizes: it discards the optimised code and drops the function back to the interpreter to re-collect feedback. A few deopts are normal warm-up; a function that deopts repeatedly (a deopt loop) is stuck paying interpreter prices on a hot path.

The triggers you control:

// 1. Hidden-class churn: this site sees C2, then C2', then dictionary-mode
//    objects -> goes polymorphic, then megamorphic, then deopts.
function sum(o) { return o.x + o.y; }

// 2. `arguments` leaking out of a function used to defeat optimisation;
//    even today, prefer rest params, which V8 reasons about cleanly:
function bad() { return Array.prototype.slice.call(arguments); } // avoid
function good(...args) { return args; }                          // optimisable

Historically try/catch and arguments misuse blocked optimisation outright; modern TurboFan handles try/catch fine, but shape churn and type instability remain the reliable deopt triggers. Keep the shapes and types a hot function sees constant and it climbs to TurboFan and stays there.

Garbage collection: why short-lived allocations are cheap

V8’s heap is generational, built on the empirical fact that most objects die young. New objects go in the young generation (a small space split into two semi-spaces, from and to). Collection there — the Scavenge — is a cheap copying collector: it copies the still-live objects from from to to, then declares the whole from space free in one move. Because it only touches survivors and most objects are already dead, a Scavenge is fast and frequent.

Objects that survive a couple of Scavenges are promoted to the old generation, collected by Mark-Sweep-Compact: mark everything reachable, sweep the dead, occasionally compact to fight fragmentation. This is the expensive, less frequent collector. The takeaway for hot code: a short-lived allocation inside a request — a temporary array, an intermediate object — is genuinely cheap because it dies in the young space and is reclaimed by a fast Scavenge. What hurts is promoting garbage: holding references that keep objects alive just long enough to reach the old generation, where collecting them is costly. Pool or reuse only when profiling proves a real Scavenge/promotion problem — premature object pooling often adds old-gen pressure.