Inline caches

Lookups become remembered work

A naive property lookup is a search. The engine checks the object, searches its own properties, and then walks the prototype chain until it finds a matching name or gives up. That flexible rule is why obj.x works even when x lives on a prototype.

The “inline” part is historical: early Smalltalk and JavaScript engines patched a tiny fast path near the operation. Modern engines may store feedback in vectors and stubs instead, but the mental model is the same: each call site learns from the shapes it actually sees.

1const record = { user: { name: "Ada" } };2const proto = { role: "author" };3Object.setPrototypeOf(record.user, proto);4 5function naiveLookup(object, name) {6  let current = object;7  while (current) {8    if (Object.prototype.hasOwnProperty.call(current, name)) {9      return current[name];10    }11    current = Object.getPrototypeOf(current);12  }13  return undefined;14}15 16console.log(naiveLookup(record.user, "name"));17console.log(naiveLookup(record.user, "role"));

Line 6 asks whether the current object owns the property. Line 10 moves to the prototype. Engines cannot afford that search on every hot read, so they attach a specialized stub after the first miss proves where the property lives.

This lesson sits after type feedback and before deeper hidden-class lessons. If the words shape, map, and hidden class are new, use the small definition here and revisit object basics, the prototype chain, classes, and property descriptors. The later Hidden classes & object shapes lesson goes deeper.

Shapes, maps, and offsets

Engines use different names, but the useful idea is shared: objects with the same property layout share a hidden class, map, or shape. That layout stores where each property lives. If x is at offset 0 for shape S, the engine can load slot 0 after checking S.

1function makeUser(name) {2  return { name, score: 0, active: true };3}4 5const ada = makeUser("Ada");6const lin = makeUser("Lin");7const reordered = { score: 0, name: "Grace", active: true };8 9console.log(Object.keys(ada).join(","));10console.log(Object.keys(lin).join(","));11console.log(Object.keys(reordered).join(","));

This snippet only prints key order because browser JavaScript does not expose maps. The real evidence below uses Node 22.23.1 with V8 native syntax in a child process. It is marked non-runnable in the browser editor on purpose.

1function Point(x) {2  this.x = x;3}4 5const a = { x: 1, y: 2 };6const b = { x: 3, y: 4 };7const c = { y: 2, x: 1 };8const p = new Point(1);9const q = new Point(2);10 11console.log(`Node ${process.versions.node} (V8 ${process.versions.v8.split(".").slice(0, 2).join(".")})`);12console.log("same property order", %HaveSameMap(a, b));13console.log("different property order", %HaveSameMap(a, c));14console.log("constructor start", %HaveSameMap(p, q));15p.y = 2;16console.log("after one transition", %HaveSameMap(p, q));17q.y = 3;18console.log("after both transition", %HaveSameMap(p, q));

The V8 team explains the internal property-store distinction in Fast properties in V8, and the V8 maps docs show that a map is the first pointer used to compare an object's hidden class. Mathias Bynens and Benedikt Meurer's Shapes and Inline Caches article is the high-level companion.

Monomorphic inline caches: one shape, one load

Inline caches belong to operation sites, not to property names globally. Two different obj.x expressions have separate feedback. At one site, the first object misses, the engine runs the slow lookup, then attaches a stub for that shape and offset.

1function createGetXSite() {2  let cachedShape = null;3  let cachedOffset = "x";4  return function getX(record) {5    if (record.shape === cachedShape) {6      return record.slots[cachedOffset];7    }8    cachedShape = record.shape;9    return record.slots.x;10  };11}12 13const getX = createGetXSite();Run14const a = { shape: "x,y", slots: { x: 1, y: 10 } };15const b = { shape: "x,y", slots: { x: 2, y: 20 } };16console.log(getX(a));17console.log(getX(b));

Step through the replay. The first getX(a) call records the shape and the offset for x. The second call receives a different object with the same shape, so the IC can do exactly what optimizing compilers want: check the map, then load the slot.

Polymorphic to megamorphic

Real programs often send two or three stable layouts through one helper. That is polymorphic feedback: the site has a short list of shape-specific stubs. In V8 12.4, the source and tests for this lesson verify the polymorphic map budget as four; a fifth distinct map pushes the site into megamorphic handling. Treat the exact number as implementation detail, not JavaScript semantics.

1const limit = 4;Run2const site = { state: "uninitialized", entries: [], stubCache: new Map() };3 4function readX(record) {5  const key = record.shape + ":x";6  if (site.state === "megamorphic" && site.stubCache.has(key)) {7    return site.stubCache.get(key)(record);8  }9  if (site.entries.includes(record.shape)) {10    return record.slots.x;11  }12  if (site.entries.length === limit) {13    site.state = "megamorphic";14    site.stubCache.set(key, (object) => object.slots.x);15    return record.slots.x;16  }17  site.entries.push(record.shape);18  site.state = site.entries.length === 1 ? "monomorphic" : "polymorphic";19  return record.slots.x;20}21 22const records = [23  { shape: "S1", slots: { x: 1 } },24  { shape: "S2", slots: { x: 2 } },25  { shape: "S3", slots: { x: 3 } },26  { shape: "S4", slots: { x: 4 } },27  { shape: "S5", slots: { x: 5 } },28];29 30for (const record of records) console.log(readX(record));31console.log(readX(records[4]));

1const site = createInlineCacheSite("getX");2const objects = [3  makeObject([["x", 1], ["a", 10]], "x-a"),4  makeObject([["a", 20], ["x", 2]], "a-x"),5  makeObject([["x", 3], ["b", 30]], "x-b"),6  makeObject([["b", 40], ["x", 4]], "b-x"),7  makeObject([["c", 50], ["x", 5]], "c-x"),8];9 10for (const object of objects) {11  console.log(site.read(object, "x"));12}

V8's megamorphic named-load path uses broader lookup machinery and a stub cache keyed by information such as the receiver map and property name. That keeps one noisy site from growing unlimited local code, but it is slower than a tiny monomorphic guard.

Keyed, store, call, and global ICs

Property loads are the easiest IC to picture, but feedback exists for many dynamic operations. A keyed IC for obj[key] has to separate named properties from element access. Arrays add another dimension: packed arrays, holey arrays, integer elements, doubles, and object elements each give different feedback.

1function readKey(target, key) {2  return target[key];3}4 5const user = { name: "Ada" };6const packed = ["zero", "one", "two"];7const holey = [];8holey[2] = "two";9 10console.log(readKey(user, "name"));11console.log(readKey(packed, 1));12console.log(0 in holey);13console.log(readKey(holey, 2));

Store ICs learn whether a write updates an existing slot or creates a shape transition. Call ICs learn callable targets and receiver shapes, which is why a monomorphic call site can later be inlined by an optimizing compiler.

1function writeX(object, value) {2  object.x = value;3  return object.x;4}5 6const a = { x: 0, y: 0 };7const b = { x: 1, y: 1 };8const c = { y: 0 };9 10console.log(writeX(a, 7));11console.log(writeX(b, 8));12console.log(Object.keys(c).join(","));13console.log(writeX(c, 9));14console.log(Object.keys(c).join(","));

1function render(formatter, value) {2  return formatter(value);3}4 5function money(amount) {6  return "$" + amount.toFixed(2);7}8 9function label(value) {10  return "item:" + value;11}12 13console.log(render(money, 3));14console.log(render(money, 4));15console.log(render(label, "A"));

Global load ICs do similar work for names such as Math or document. Prototype-chain loads cache not only the receiver shape, but also assumptions that the prototype chain has not changed. V8 describes these dependency checks with validity cells; the later hidden classes and prototypes inside the engine lessons go deeper.

1const proto = { x: 1 };2const child = Object.create(proto);3 4console.log(child.x);5proto.x = 2;6console.log(child.x);7child.x = 3;8console.log(child.x);9console.log(proto.x);

CacheIR and other engines

SpiderMonkey documents CacheIR as the core of its speculative optimization strategy: a simple linear bytecode for inline-cache stubs. The official docs describe guards, idempotent operations, and one final result operation. Their example for a fixed property load is essentially guard the input object, guard the shape, then load the fixed slot.

1GetProp "x"2  GuardToObject input3  GuardShape shape=S14  LoadFixedSlotResult slot=0

Jan de Mooij's CacheIR post explains why Firefox moved this logic into a structured representation. The current SpiderMonkey docs say Baseline stubs are generated from CacheIR and Warp can transpile CacheIR snapshots into optimizing compiler IR. JavaScriptCore uses inline caches too; WebKit's Speculation in JavaScriptCore describes how JSC speculates from runtime evidence and guards those assumptions.

How optimizers use IC feedback

Baseline tiers gather feedback while keeping code quick to generate. When a function gets hot, an optimizing compiler can look at the IC history. A monomorphic property load can become machine code shaped like “compare receiver map with S; if it fails, deopt; otherwise load memory at offset k.” That is the single-memory-load promise in the curriculum summary.

Polymorphic sites may still optimize with a small guard chain. Megamorphic sites are harder: they say “this operation sees many unrelated shapes,” so the compiler has less to specialize and often leaves a call to generic or stub-cache machinery. Call IC feedback works the same way: one stable target can be inlined; many targets make inlining less attractive.

Practical shape-friendly code

The production advice is deliberately boring: initialize all expected properties, do it in the same order, avoid delete on hot objects, and avoid routing many unrelated object types through one tiny hot helper. Do not contort clear code for a theoretical IC win.

1function User(name, admin = false) {2  this.name = name;3  this.admin = admin;4  this.score = 0;5}6 7const ada = new User("Ada");8const lin = new User("Lin", true);9lin.score = 10;10 11console.log(Object.keys(ada).join(","));12console.log(Object.keys(lin).join(","));13delete ada.admin;14console.log(Object.keys(ada).join(","));

Lines 2 through 4 create the same layout for every User. Line 13 shows the habit to avoid in hot code: deleting a property changes the layout and can push an object away from fast-property storage. Sometimes deletion is the clearest model; just do not assume it is free inside a hot loop.

• Construct objects with the same fields in the same order.
• Prefer setting a field to null or undefined over delete when the object remains hot.
• Split a hot helper if it processes many unrelated shapes and profiling shows that site matters.
• Keep readability first, then measure before and after.

Common misconceptions

• “The IC caches values.” It caches a guarded lookup recipe; values can change.
• “One polymorphic site is always bad.” A small stable set of shapes is normal and often optimized well.
• “Megamorphic means broken.” It means the engine chose broader machinery for a diverse site; it matters only when profiling says it is hot.
• “Hidden classes are JavaScript semantics.” They are engine strategies. The language still says property lookup follows objects and prototypes.
• “Engine internals should dictate every style choice.” Clear data models, tests, and measurements beat folklore.

Practice exercises

function getX(object) {
  return object.x;
}
const a = { x: 1, y: 10 };
const b = { x: 2, y: 20 };
console.log(getX(a));
console.log(getX(b));

const holey = [];
holey[2] = "two";
console.log(0 in holey);

Check your understanding

Key takeaways

• Inline caches are per-site feedback: one obj.x expression can be monomorphic while another is megamorphic.
• Shapes/maps connect property names to offsets, so a cached load can become a shape guard plus one slot load.
• V8 12.4 uses a four-map polymorphic budget; too many shapes make a site megamorphic and push work to broader caches.
• Keyed, store, call, global, and prototype ICs all record different runtime facts for later tiers.
• Write consistent object shapes when it is natural, avoid hot delete, and measure before optimizing.

Next in this module, Baseline compilers picks up where IC feedback leaves off: fast simple compilers that remove interpreter overhead before the highest optimizing tiers take over.