Hidden Classes & Inline Caches

Here's the puzzle V8 has to solve. In a static language, point.x compiles to "read memory at offset 8" — instant. But JavaScript objects are dynamic dictionaries: you can add or delete properties any time. A naive engine would do a hash-table lookup on every point.x. That's death by a thousand cuts. V8's answer is the hidden class.

Same construction → same hidden class

Two objects have the same Map when they have the same properties, added in the same order. Let's prove it with %HaveSameMap (needs --allow-natives-syntax):

function Point(x, y) { this.x = x; this.y = y; }
const a = new Point(1, 2);
const b = new Point(3, 4);   // same constructor, same order
const c = { x: 5, y: 6 };    // literal: same property names & order...
const d = { y: 8, x: 7 };    // ...but reversed order
console.log(%HaveSameMap(a, b));  // ?
console.log(%HaveSameMap(a, c));  // ?
console.log(%HaveSameMap(a, d));  // ?
c.z = 99;                      // add a property after the fact
console.log(%HaveSameMap(a, c));  // ?

a vs b same map: true     // identical construction → shared Map
a vs c same map: false    // constructor objects ≠ plain literals here
a vs d same map: false    // property ORDER changes the shape
a vs c after z:  false    // adding a property transitioned c to a NEW Map

Two lessons jump out: property order matters ({x,y} and {y,x} are different shapes), and adding a property changes the shape. That second one is the key to transitions.

The same layout, three objects, one Map

Picture what a and b share. The Map isn't stored in each object — it's a separate descriptor they both point to. Each object only stores the values, in slots:

DebugPrint: 0x..: [JS_OBJECT_TYPE]
 - map: 0x..<Map[40](HOLEY_ELEMENTS)> [FastProperties]
 - properties: <FixedArray[0]>

Transitions: shapes form a tree

When you add z to an object shaped {x, y}, V8 doesn't mutate the Map — it transitions to a new Map {x, y, z} and records the link. The next object that goes {x, y} then adds z follows the same transition and ends up sharing that Map. This is why constructing objects the same way is so valuable: everyone walks the same path through the transition tree and shares Maps at every step.

{} ──add x──▶ {x} ──add y──▶ {x,y} ──add z──▶ {x,y,z}
                              ▲ a, b live here   ▲ c ends up here after c.z=99

Canonical reference: Maps (Hidden Classes) in V8 · best conceptual intro: Shapes and Inline Caches (Bynens & Meurer).

Inline Caches: remembering where things live

Hidden classes make a fast lookup possible; inline caches (ICs) are what make it actually fast. Every property-access site in your code (like the o.x in a function) gets a little cache attached. The first time it runs, V8 does the full lookup and records: "for Map M1, property x is at offset 0." Every subsequent call just checks "is this still M1? yes → grab offset 0." That check-and-grab is the recorded type feedback from Lesson 1, and it's what the optimizing compilers turn into a couple of machine instructions.

How many shapes an IC has seen determines its speed:

The payoff: why some JS is fast and some isn't

You can now predict performance: code that keeps shapes stable keeps its inline caches monomorphic and its optimized code alive. Code that mutates shapes forces polymorphism and deopts. That's the whole game.

Check yourself feedback loop

Where this lands you

You can now explain V8's object model — Maps, transitions, FastProperties vs dictionary mode — and inline caches, and use them to predict performance. Combined with the tier/deopt model from Lesson 2, you have the full "why JavaScript gets fast" story. The last internals lesson covers the other half of the runtime: how the garbage collector reclaims all those objects without freezing your program.

Reference: V8 Glossary (updated) · Inspection Flags · Related: Lesson 2 (deopt)