Prototypes inside the engine

Prototype lookup needs fast guards

Every object can have a prototype: another object it falls back on. When you read a property, JavaScript looks on the object first. If the property is not there, JavaScript looks on the prototype, then on the prototype's prototype, and so on. This line of objects is called the prototype chain.

The chain can change while a program runs. Code can add a property, replace a method, or give an object a new prototype. The JavaScript engine (the program inside the browser or Node that runs your code) must always give the right answer, even after such a change.

The rules of the prototype chain are covered in Prototype chain, Object.create, Class inheritance, and Native prototypes. This lesson is about the engine side. The lesson before this one, Functions & closures inside the engine, showed how the engine stores functions. Here you see how it finds methods that live on a prototype.

First, the rules the engine must keep. The code below uses two tools:

• Object.create(proto) makes a new, empty object whose prototype is proto.
• Object.setPrototypeOf(obj, other) gives an existing object obj a new prototype, other.

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 7 makes child, with proto as its prototype.
• Line 9 reads child.label. child has no label of its own, so JavaScript finds it on proto and prints from prototype.
• Line 10 gives child its own label. An object's own property hides a prototype property with the same name. This is called shadowing.
• Line 11 prints own label. Line 12 prints proto.label, which is still from prototype.
• Lines 13 to 15 put a new method on proto. Line 16 calls it through child and prints new method.
• Line 17 gives child a new prototype. Line 18 deletes the own label. Line 19 prints new prototype, read from the new prototype.

Any shortcut the engine saves must still print these same five lines.

Prototype maps

The engine keeps a hidden note for every object. The note lists which properties the object has and where each one is stored. V8 (the engine in Chrome and Node) calls this note a map. SpiderMonkey (the engine in Firefox) calls it a shape. Both words mean the same thing here. Your code never sees a map.

Many objects can share one map when they have the same properties, added in the same order. The hidden classes lesson explains maps in depth. Here you need one new idea: an object that other objects use as their prototype gets extra notes, because many objects now depend on it.

The table below lists the engine words used in this lesson. Read each row from left to right: the word, what it means, and why it matters for prototypes.

Mathias Bynens and Benedikt Meurer, who worked on V8, describe one useful trick. An object's map also records which prototype the object links to. So one check of the map answers two questions at once:

• Does this object still lack its own copy of the property?
• Does this object still link to the same prototype?

You can see the extra notes in Node with special V8 commands. Commands that start with %, like %DebugPrint, only work when Node runs with the --allow-natives-syntax flag. They are not normal JavaScript, so this code does not run in the browser.

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;

• Lines 1 to 6 make a normal object, proto.
• Lines 7 to 9 print the Node and V8 version.
• Line 10 asks V8 whether proto uses its normal, fast way of storing properties. It prints true.
• Line 11 makes rect with proto as its prototype. Line 12 asks again and now prints false.
• Line 13 prints everything V8 knows about proto.

You don't need to remember the exact printout. The main point: a prototype is still a normal JavaScript object. But once other objects depend on it, the engine marks it and keeps an eye on it.

Caching inherited property lookups

A method call does two jobs. Take rect.getArea():

1. JavaScript finds getArea. This is a normal property read.
2. JavaScript calls that function with this set to rect.

The first job can be slow if the engine walks the whole chain on every call. Step through it below.

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());

• Line 6 makes rect with its own width and height.
• Line 7 links rect to rectPrototype.
• Line 9 asks for getArea. rect does not have it, so JavaScript finds it on the prototype.
• Line 3 runs inside the method. It reads width and height from rect, because this is rect. The method is shared, but the numbers belong to each object.

To skip the walk next time, the engine saves a shortcut at that line of code. A saved shortcut like this is called a cache. The table below shows what happens on each read. Each row is one moment: what JavaScript does, and what the shortcut saves or does.

The inline caches lesson showed shortcuts for an object's own properties. A shortcut for an inherited property saves more:

• The map of the object you read from, like rect.
• Which prototype has the property.
• The slot: the place in that prototype where the value is stored.
• A validity cell: a small flag that says the chain has not changed. The next section explains it.

Validity cells

A validity cell is a tiny flag inside the engine. It says either "valid" or "invalid". Many saved shortcuts can share one cell. Here is how V8 uses it:

1. When a shortcut is saved, it keeps a link to the current cell.
2. If a prototype on the chain changes, the engine marks that cell invalid.
3. The next time a shortcut runs, it sees the invalid cell. It walks the chain again and saves a fresh shortcut.

The code below is a small model of this, written in plain JavaScript. It is not the real engine. Step through it to watch one shortcut being saved, used, and refused.

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)());

• Line 18 is the first read. Nothing is saved yet, so the model walks to the prototype and saves a shortcut.
• Line 19 is the second read. The map matches and the cell is valid, so the model uses the shortcut.
• Line 20 marks the old cell invalid. Line 22 replaces the method with one that returns 20.
• Line 23 is the third read. The old cell is invalid, so the model walks again, saves a fresh shortcut, and prints 20.

The shortcut never saves the value 12. It saves a safe way to reach the slot. So after the change, line 23 prints 20, as JavaScript requires. The price of the change is that old shortcuts stop working and must be saved again.

V8's article on prototype speed-ups warns that changing Object.prototype is the widest change of all. Almost every object has Object.prototype at the end of its chain. So changing it can mark many cells invalid at once, including the chains of page elements in a browser. That is why adding to global prototypes after an app has started running is expensive.

Shape teleporting in SpiderMonkey

SpiderMonkey is Firefox's engine. It uses the word shape where V8 says map. It has its own trick for long chains, called shape teleporting. The goal: don't check every object in the middle of the chain on every read.

The block below is a sketch, not real code. It uses three made-up steps:

• GuardShape(x) checks that object x still has the same shape.
• LoadSlot(x, "y") reads the value of y from its slot in x.
• holderPrototype is the prototype that has y. middlePrototype sits between it and obj.

1Simple shortcut for obj.y (checks every object):2  GuardShape(obj)3  GuardShape(middlePrototype)4  GuardShape(holderPrototype)5  LoadSlot(holderPrototype, "y")6 7SpiderMonkey shape teleporting (checks two):8  GuardShape(obj)9  GuardShape(holderPrototype)10  LoadSlot(holderPrototype, "y")11  If middlePrototype gets its own "y":12    change shapes, so the old checks fail

• Lines 1 to 5: a simple shortcut checks all three objects, then reads y.
• Lines 7 to 10: shape teleporting checks only obj and holderPrototype, then reads y.
• Lines 11 and 12: the rule that keeps this safe. If middlePrototype gets its own y, SpiderMonkey changes the shapes, so the old checks fail.

Matthew Gaudet's post about SpiderMonkey explains why the rule is needed. Skipping the middle check is only safe if any change in the middle also changes a shape that is checked. SpiderMonkey makes sure of that. It changes shapes when a middle prototype starts shadowing the property, and when a prototype link changes.

Shape teleporting is not a new JavaScript feature. The rules still say a lookup walks the chain. Shape teleporting only lets SpiderMonkey get the same answer with fewer checks.

Why changing a prototype is slow

You may change a prototype with Object.setPrototypeOf or by assigning to __proto__. Both are allowed. But both break facts that saved shortcuts and fast code rely on. MDN warns that changing an object's prototype is slow in modern engines. The cost is not only in that one line. Other code that was made fast for the old chain can slow down too.

When a function runs many times, V8 turns it into fast machine code. This is called optimizing. If a fact that the fast code relied on stops being true, V8 throws that code away and goes back to slower code. This is called deoptimizing.

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));

• Line 8 defines area, which calls object.getArea().
• Line 12 tells V8 to get ready to optimize area. Line 13 runs it 10,000 times. Line 14 tells V8 to optimize it on the next call.
• Line 15 prints before 12, using the fast code.
• Line 16 replaces getArea on the prototype. Line 19 prints after 20.

Replacing a method is not the same as adding a property. The method still sits in the same slot, so a simple shortcut to the slot can still work. But the fast code may have copied the old function into itself, or checked for it. So V8 tracks that separately, and the next call still gives the right answer.

Experiment: change the prototype chain

This playground is a small model of the shortcut. Each change has one of three results:

• The validity cell turns invalid, so the shortcut is refused.
• The object's map changes, so the map check fails.
• The shortcut can still be used.

Press Read area twice first, so there is a shortcut to reuse. Then try each change and read again.

1const site = createInheritedLoadSite("getArea");2const rect = makeRect(3, 4);3 4site.read(rect);                 // first read: walk, save a shortcut5site.read(rect);                 // uses the shortcut6rect.width = 5;                  // shortcut still works7rect.__proto__.perimeter = 18;   // new prototype map, cell turns invalid8site.read(rect);                 // shortcut refused: walk, save again

Practical use

Most developers never need to think about prototype maps. The useful habits are simple:

• Give each object the right prototype when you create it.
• Don't change prototypes in code that runs very often.
• Don't add to built-in prototypes after the app has started.
• Measure before you rewrite readable code for speed.

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());

Line 1 makes one object that holds the shared method. Lines 7 and 12 use Object.create to set the prototype at the moment each object is made. Lines 10 and 15 print 12 and 10. This is different from making an object, using it many times, and then changing its prototype. If a library must add to a prototype, doing it before the busy code starts is less harmful than doing it in the middle.

• Make objects with Object.create(proto), a class, or a constructor function. Don't change their prototype later.
• Don't add to Object.prototype or other built-in prototypes in code that runs often.
• Changing an object's own data, like rect.width, is fine. The method's result changes, but the shortcut to the method still works.
• Use a profiler (a tool that measures where time goes) before you change your design for prototype speed.

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

Common misconceptions

• "The engine saves inherited values." It saves a checked way to reach the slot. The value in the slot can still change.
• "Changing a prototype only costs that one line." It can also throw away fast code that relied on the old chain.
• "A prototype map is a JavaScript feature." Maps, shapes, and validity cells belong to the engine. The language does not mention them.
• "Shape teleporting breaks the lookup rules." It skips checks only when shape changes keep the answer correct.
• "All prototype changes cost the same." Adding a prototype property, replacing a method, changing an object's data, and setting a new prototype each break different checks.

The table below compares ideas that look alike. Each row says what the idea means, and what it does not mean.

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());

// Problem: this line runs after the app has been busy for a while.
Object.setPrototypeOf(card, premiumCardMethods);

const card = Object.create(premiumCardMethods);

Check your understanding

For each question, first work out what JavaScript prints. Then name the engine check that keeps the shortcut correct.

Key takeaways

• Every method call starts with a property read. Shortcuts make that read faster. They never change this or the shadowing rules.
• In V8, an object used as a prototype gets extra notes, such as prototype info and a validity cell.
• A saved shortcut checks the object's map and the validity cell. Then it reads straight from the prototype's slot.
• SpiderMonkey's shape teleporting skips checks on middle prototypes. It stays correct because changes in the middle change a shape that is checked.
• Changing prototypes, or adding to built-in prototypes, after code has run many times can throw away a lot of fast code. Set the prototype when you create the object, and measure first.

In one line: the engine trusts its saved shortcuts to prototypes only while their checks still pass.

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