Prototypes inside the engine

Prototype lookup needs fast guards

JavaScript's prototype chain is flexible. A property can live on the receiver, on its direct prototype, or higher up the chain. That flexibility is language semantics: engines must return the same value even after shadowing, method replacement, or Object.setPrototypeOf changes the chain.

We will not repeat the language semantics covered in Prototype chain, Object.create, Class inheritance, and Native prototypes. Instead, we will look at the engine side. The previous batch lesson, Functions & closures inside the engine, explained function objects and feedback cells. This lesson connects that to inherited methods.

1const proto = {2  label: "from prototype",3  method() {4    return "old method";5  },6};7const child = Object.create(proto);8 9console.log(child.label);10child.label = "own label";11console.log(child.label);12console.log(proto.label);13proto.method = function method() {14  return "new method";15};16console.log(child.method());17Object.setPrototypeOf(child, { label: "new prototype" });18delete child.label;19console.log(child.label);

Line 8 reads label from the prototype. Line 9 creates an own property that shadows it, so line 10 prints the own value while line 11 proves the prototype is unchanged. Lines 13 through 16 replace the method on the prototype, and the instance sees the new method. Lines 17 and 18 then change the prototype link and remove the shadow, so the next lookup reaches the new prototype.

Prototype maps

A map or shape is engine metadata describing an object's layout. The neighbouring hidden-classes lesson goes deeper on map transition trees and descriptors. Here we only need one extra idea: prototypes get special bookkeeping because many receivers can depend on them for inherited lookups.

Mathias Bynens and Benedikt Meurer describe a key trick used by engines: the receiver's shape can include the prototype link. A single receiver-map check can therefore prove both “this object still lacks the property” and “this object still points to that prototype.”

1const proto = {2  kind: "rect",3  getArea() {4    return 12;5  },6};7console.log(8  `Node ${process.versions.node} (V8 ${process.versions.v8.split(".").slice(0, 2).join(".")})`,9);10console.log("before fast properties", %HasFastProperties(proto));11const rect = Object.create(proto);12console.log("after used as prototype", %HasFastProperties(proto));13%DebugPrint(proto);14void rect;

The important lesson is not the exact DebugPrint text. It is that a prototype is still a JavaScript object, but the engine marks and tracks it differently once other objects depend on it.

Caching inherited property lookups

Every method call begins with a property load. rect.getArea() first loads getArea, then calls the function with rect as this. That first step can be expensive if the engine walks the chain every time.

1const rectPrototype = {Run2  getArea() {3    return this.width * this.height;4  },5};6const rect = { width: 3, height: 4 };7Object.setPrototypeOf(rect, rectPrototype);8 9console.log(rect.getArea());

Step through the replay. Line 6 creates the receiver with width and height. Line 7 links the prototype. Line 9 asks for getArea. The method body on line 3 still reads data from the receiver, not from the prototype, because the call uses this = rect.

The inline-caches lesson introduced receiver-map guards for own properties and briefly mentioned prototype-chain ICs. Here the cached recipe is richer: receiver map, holder prototype, offset, and a validity cell that says the relevant chain has not changed.

Validity cells

A validity cell is a tiny piece of engine state that many optimized paths can check. In V8's prototype-load model, the cached load records the current cell. If a relevant prototype changes, the old cell becomes invalid. The next cache hit fails the cell check and falls back to a fresh lookup.

1let validityCell = { valid: true };Run2const cache = { receiverMap: null, holder: null, offset: null, cell: null };3const rectProto = { slots: { getArea() { return 12; } } };4const rect = { map: "RectMap#1", prototype: rectProto };5 6function loadGetArea(receiver) {7  if (cache.receiverMap === receiver.map && cache.cell?.valid) {8    return cache.holder.slots[cache.offset];9  }10  const holder = receiver.prototype;11  cache.receiverMap = receiver.map;12  cache.holder = holder;13  cache.offset = "getArea";14  cache.cell = validityCell;15  return holder.slots.getArea;16}17 18console.log(loadGetArea(rect)());19console.log(loadGetArea(rect)());20validityCell.valid = false;21validityCell = { valid: true };22rectProto.slots.getArea = () => 20;23console.log(loadGetArea(rect)());

The important detail is that the cache does not store the value 12. It stores a safe path to the slot. After the mutation, line 23 returns 20 because JavaScript semantics win. The cost is paid by invalidating old assumptions and refreshing the cache.

V8's public prototype-optimization article says changing Object.prototype is especially broad: it can invalidate prototype loads below it, including DOM-related chains in browsers. That is why patching global prototypes after an app has warmed up is expensive.

Shape teleporting in SpiderMonkey

SpiderMonkey, Firefox's engine, uses the word shape where V8 often says map. Its “shape teleporting” optimization answers the same pressure: long prototype chains should not require a guard for every intermediate object on every hot lookup.

1Naive prototype-chain cache for obj.y:2  GuardShape(obj)3  GuardShape(obj.[[Prototype]])4  GuardShape(intermediatePrototype)5  GuardShape(holderPrototype)6  LoadSlot(holderPrototype, "y")7 8SpiderMonkey shape teleporting model:9  GuardShape(obj)10  GuardShape(holderPrototype)11  LoadSlot(holderPrototype, "y")12  Reshape holders if an intermediate prototype starts shadowing "y"

Matthew Gaudet's SpiderMonkey post explains the rule carefully: if a property is found on holder prototype B, the cache would like to guard only the receiver and B. That is safe only if SpiderMonkey reshapes objects when an intermediate prototype starts shadowing the property, or when prototype links mutate.

This is an engine strategy, not a new JavaScript feature. The specification still says lookup walks the chain. Shape teleporting is how SpiderMonkey can make the common case behave as if it walked, while doing fewer checks.

Why changing a prototype is slow

Object.setPrototypeOf and __proto__ assignment are legal, but they change the assumptions optimized code uses. MDN warns that changing an object's [[Prototype]] is slow in modern engines, and the effects can extend beyond the single statement because other code may have optimized around the old chain.

1const proto = {2  getArea() {3    return 12;4  },5};6const rect = Object.create(proto);7 8function area(object) {9  return object.getArea();10}11 12%PrepareFunctionForOptimization(area);13for (let i = 0; i < 10000; i += 1) area(rect);14%OptimizeFunctionOnNextCall(area);15console.log("before", area(rect));16proto.getArea = function getArea() {17  return 20;18};19console.log("after", area(rect));

Replacing a method value is not identical to adding a property. A simple inherited load can still know the slot, but optimized call code may have inlined or guarded the old function target. Engines keep separate dependencies so the next call remains correct.

Experiment: mutate the prototype chain

Use this teaching model to separate three outcomes: a validity-cell invalidation, a receiver-map miss, and a lookup that can stay cached. Start with two reads so the cache has something to reuse, then try each mutation.

1const site = createInheritedLoadSite("getArea");2const rect = makeRect(3, 4);3 4site.read(rect);                 // cold miss, installs cache5site.read(rect);                 // cache hit6rect.width = 5;                  // cached lookup can stay7rect.__proto__.perimeter = 18;   // prototype map + validity cell change8site.read(rect);                 // validity-cell miss, then refreshed cache

Practical use

Most developers should not micro-manage prototype maps. The practical advice is simple: create objects with the prototype you want, avoid changing prototypes on hot paths, avoid patching native prototypes after startup, and measure before rewriting readable code.

1const rectMethods = {2  getArea() {3    return this.width * this.height;4  },5};6 7const card = Object.create(rectMethods);8card.width = 3;9card.height = 4;10console.log(card.getArea());11 12const nextCard = Object.create(rectMethods);13nextCard.width = 5;14nextCard.height = 2;15console.log(nextCard.getArea());

Lines 7 and 12 use Object.create to choose the prototype at construction time. That is different from taking a warmed object and changing its prototype link later. If a framework or polyfill must patch a prototype, doing it before the app's hot code runs is less disruptive than changing it mid-flight.

• Create objects with Object.create(proto), a class, or a constructor instead of changing prototypes later.
• Do not patch Object.prototype or native prototypes in application hot paths.
• Changing ordinary receiver data is fine; the method result can change without invalidating the inherited method lookup.
• Use a profiler before changing architecture for prototype performance.

The next lesson, The heap & pointer compression, moves from prototype metadata to how values and objects are placed in memory.

Common misconceptions

• “The engine caches inherited values.” It caches guarded lookup recipes; the value in the slot can still change.
• “Changing one prototype only costs that one line.” It can invalidate optimized code that depended on the old chain.
• “A prototype map is a JavaScript feature.” Maps, shapes, and validity cells are implementation details.
• “Shape teleporting skips semantics.” It skips repeated checks only when reshaping rules keep semantics correct.
• “All prototype mutations are equally bad.” Adding a prototype property, replacing a method value, changing receiver data, and setting a new prototype break different assumptions.

Practice exercises

const proto = { price: 100 };
const item = Object.create(proto);
console.log(item.price);
item.price = 120;
console.log(item.price);
console.log(proto.price);

const proto = { tag() { return "old"; } };
const item = Object.create(proto);
proto.tag = function tag() { return "new"; };
console.log(item.tag());

// Bug: this runs after the app has warmed up.
Object.setPrototypeOf(card, premiumCardMethods);

const card = Object.create(premiumCardMethods);

Check your understanding

Answer by separating JavaScript semantics from the engine guard that keeps a fast path safe.

Key takeaways

• Inherited method calls begin with a property lookup; caches speed up that lookup without changing this or shadowing rules.
• V8 prototype maps carry prototype-specific bookkeeping such as prototype info and prototype validity cells.
• A cached inherited load can check the receiver map and validity cell, then load directly from the holder prototype's slot.
• SpiderMonkey shape teleporting skips intermediate prototype guards only because reshaping rules invalidate unsafe shortcuts.
• Changing prototypes or patching global prototypes after warm-up can invalidate broad engine assumptions; create with the right prototype and measure first.

One-line summary: prototype fast paths work by trusting guarded chain facts until a prototype or receiver-map change proves those facts stale.

Next: The heap & pointer compression explains where these objects, maps, and values live in memory.