Hidden Classes And Inline Caches

By making objects not be hash maps most of the time. V8 attaches to every object a map (the hidden class): a description of which named properties the object has, in what order, at what memory offsets, with what attributes. Objects built the same way share a map. An inline cache that has seen one object with map M knows the offset of x for every object with map M, so the load is a map comparison and a fixed-offset read. The dictionary is kept in reserve for objects that stop behaving like structs.

The map tree is built lazily as programs add properties, shared across every object that walks the same path, and abandoned by objects that do something the tree cannot describe.

// same shape: one map, monomorphic everywhere they flow
class Point { constructor(x, y) { this.x = x; this.y = y } }
const a = new Point(1, 2), b = new Point(3, 4)
%HaveSameMap(a, b)   // true

// different shape: optional property added conditionally
function make(x, y, z) { const p = { x, y }; if (z !== undefined) p.z = z; return p }
%HaveSameMap(make(1, 2), make(1, 2, 3))   // false: {x,y} vs {x,y,z}

// fix: always define every property, in the same order
function make(x, y, z) { return { x, y, z: z ?? null } }
%HaveSameMap(make(1, 2), make(1, 2, 3))   // true

// same shape, different representation: an int field that becomes a double
const c = { v: 1 }, d = { v: 1.5 }
%HaveSameMap(c, d)   // false: field v has representation Smi in c's map, Double in d's
// (the engine generalises c's map on the first double store; a deopt for code that trusted Smi)

A JSObject's memory is a short header followed by in-object property slots, with two side arrays for overflow: named properties beyond the in-object capacity, and indexed properties. Each has a fast representation and a slow one, and the map records which.

An array is an object whose elements store is the main event. The elements store has a kind, tracked in the map, that says how values are represented (small integers, doubles, anything) and whether there are holes. The kind only generalises, never specialises, and optimised code is compiled for the kind it saw.

An inline cache is a feedback slot plus the code that consults it. In the interpreter the IC is a handler that checks the slot; in optimised code the IC's state at compile time is baked into the generated instructions. The three states produce three very different pieces of code for the same source.

// a method call: o.greet()
//   1. load o's map, check against feedback        (the receiver's shape)
//   2. the property "greet" is NOT on o: the map says so (fast: the map knows its own properties)
//   3. the feedback also recorded: found on prototype P at depth 1, as a constant function
//   4. a "prototype chain validity cell" guards that no object between o and P changed
//   5. so: one map check + one cell check → the function pointer is a compile-time constant → inlinable

// what breaks it:
Point.prototype.greet = otherFn     // invalidates the cell; every optimised caller deopts once
o.greet = ownFn                     // o transitions to a map WITH greet; callers go polymorphic
Object.setPrototypeOf(o, other)     // o gets a new map; prototype chain reshuffled; slow for a while

Every rule of thumb about fast objects is a statement about maps, elements kinds or IC states. Here they are with the mechanism beside each, so you can tell which ones apply to your code and which are cargo.