Type feedback & feedback vectors

The engine learns from the values your code really uses

A JavaScript engine is the program inside a browser or Node that runs your code. In JavaScript, a variable has no fixed type. The same a + b can add two numbers on one call and join two strings on the next.

So the engine can't know from the code alone what a + b will get. Instead, it watches. Each time the code runs, the engine writes a short note: "this + got two small whole numbers." Later, it uses those notes to make faster code for the values it has seen.

This lesson comes after tiered compilation and before inline caches. Here you learn where the notes are kept and how they change. Later lessons show how the engine uses the notes to make fast code, and what it does when a guess turns out wrong.

These lessons help if you want to look back: data types, numbers in depth, type coercion, bytecode and interpreters, and measuring performance.

At first, the notes are empty. The engine starts every function in its interpreter: the part that runs bytecode, a simple list of steps made from your code. While it runs each step, it writes down what that step saw.

In V8, the engine in Chrome and Node, the interpreter is called Ignition. V8's faster compilers, Maglev and TurboFan, read the notes later. But first, the notes have to be filled in with real values.

The code below is a small model of this, written in plain JavaScript. It keeps notes for one +. The names of the states, like SignedSmall, are V8's real names:

• SignedSmall: small whole numbers, like 1 and 2.
• Number: any numbers, including decimals like 1.5.
• String: only strings.
• Any: a mix, so anything can come.

1const slot = createSlot("add slot #0");2 3function createSlot(id) {4  return { id, state: "None", count: 0 };5}6 7function classify(left, right) {8  if (Number.isInteger(left) && Number.isInteger(right)) return "SignedSmall";9  if (typeof left === "number" && typeof right === "number") return "Number";10  if (typeof left === "string" && typeof right === "string") return "String";11  return "Any";12}13 14function merge(previous, observed) {15  if (previous === "None" || previous === observed) return observed;16  if ((previous === "SignedSmall" && observed === "Number") || (previous === "Number" && observed === "SignedSmall")) return "Number";17  return "Any";18}19 20function specialize(state) {21  return {22    SignedSmall: "int add fast path",23    Number: "number add fast path",24    String: "string concatenate fast path",25    Any: "generic add path",26  }[state] ?? "collecting in the interpreter";27}28 29function callAdd(slot, left, right) {30  const observed = classify(left, right);31  slot.state = merge(slot.state, observed);32  slot.count += 1;33  const result = left + right;34  return {35    result,36    summary: slot.state + " -> " + specialize(slot.state),37  };38}39 40function callOptimizedAdd(plan, left, right) {41  return left + right;42}43 44console.log(callAdd(slot, 1, 2).summary);45console.log(callAdd(slot, 1.5, 2.25).summary);46console.log(callAdd(slot, "1", "2").summary);

Line by line:

1. Line 1 makes one empty slot. A slot is the place where the notes for one operation are kept.
2. Lines 7 to 12, classify, look at the two values of one call and name their kind.
3. Lines 14 to 18, merge, mix the new kind with the old notes. The notes only get wider, never narrower.
4. Lines 20 to 27, specialize, name the fast plan that would fit the current state.
5. Lines 29 to 38, callAdd, do one addition and update the slot.
6. Lines 44 to 46 call the same slot three times and print the state after each call.

The first line printed is SignedSmall -> int add fast path. The decimals 1.5 and 2.25 widen the state to Number. Then two strings arrive. A + with strings joins them instead of adding, so this slot becomes Any.

1const slot = createSlot("add slot #0");Run2callAdd(slot, 1, 2);3callAdd(slot, 3, 4);4callAdd(slot, 1.5, 2.25);

Each slot belongs to one place in the code. A different + in the same function has its own slot. That slot could stay String or SignedSmall forever. The engine makes fast code for each place, not for the + sign everywhere.

In V8, each function keeps all its slots together in one list. That list is called a FeedbackVector. There are three parts to know:

• The JSFunction is the function object your code holds.
• The FeedbackCell is a small holder that the function points to.
• The FeedbackVector is the full list of slots. The cell points to it once it exists.

V8 does not make the full vector right away. It waits until the function has run enough times. Many functions run only once or never, so this saves memory. V8 calls this lazy feedback allocation: "lazy" means "only when it is needed", and "allocation" means setting memory aside.

You can see the slot number in the bytecode. Node prints the bytecode of a function when you pass it the flag --print-bytecode:

1$ node --print-bytecode --print-bytecode-filter=add add.js2[generated bytecode for function: add]3Parameter count 34   19 S> ... @    0 : 0b 04             Ldar a15   28 E> ... @    2 : 3b 03 00          Add a0, [0]6   32 S> ... @    5 : ae                Return

Look at line 5, Add a0, [0]. The [0] is not an array. It is the number of the feedback slot for this add step. Once the function has run enough, slot 0 of its vector holds the notes for this +.

A slot is not only for +. V8 has slots for many operations: calls, reading and writing properties, math and comparisons, for...in loops, instanceof, typeof, copying objects, and literals like {} and []. You don't need to learn the list. It shows that the notes say much more than "the type of a variable".

Read each row of the table as: "for this operation, the slot writes down this, and the engine uses it like this."

1function readName(user) {2  return user.name;3}4 5console.log(readName({ name: "Ada", role: "admin" }));6console.log(readName({ name: "Grace", role: "engineer" }));

Line 2 reads user.name. Lines 5 and 6 call it with two objects that have the same properties in the same order, so it prints Ada, then Grace. The slot for line 2 writes down the object's shape: V8's record of which properties an object has and where each one is stored. V8 calls a shape a map.

These notes feed the inline caches you'll meet in the next lesson. That lesson also explains the names monomorphic (one shape), polymorphic (a few shapes), and megamorphic (many shapes).

1function apply(fn, value) {2  return fn(value);3}4 5function inc(value) {6  return value + 1;7}8 9let calls = 0;10for (const value of [1, 2, 3]) {11  calls += 1;12  apply(inc, value);13}14 15console.log("target: " + inc.name);16console.log("calls: " + calls);

The call fn(value) on line 2 runs inc every time. Lines 15 and 16 print target: inc and calls: 3, to show in plain JavaScript what the call slot would note: the same function, called again and again.

When a call always runs the same function, the faster compiler may inline it: copy the function's body into the place of the call, so no call is needed. Slots for literals remember where an object or array was made, so the next {} or [] from that line does not start from nothing.

A function that has just started is cold. A function that has run many times is hot. A cold function pays for a few things first:

• Turning the code into bytecode.
• Running slowly in the interpreter.
• Making the feedback vector, once it has run enough.
• Filling the slots with notes.
• Waiting until the engine decides it is hot enough for a faster compiler.

So the first runs are the least typical runs. If you time only them, you mostly time this setup work. Running the code many times before you start timing is called warm-up.

1function add(a, b) {2  return a + b;3}4 5for (let i = 0; i < 10000; i += 1) {6  add(i, i + 1);7}8 9console.log("warmed with 10000 number calls");10console.log(add(1, 2));

Lines 5 and 6 call add 10,000 times with numbers. Line 9 prints warmed with 10000 number calls, and line 10 prints 3. The loop does not make add faster by itself. It gives the engine time to collect notes about numbers. If add stays hot, the engine can then make fast code for numbers.

Warm-up only helps if the values match the ones you time. The fast code has a guard: a quick check in front that asks "are these the values I was made for?" If the answer is no, the engine leaves the fast code. That is called a deopt, short for deoptimization.

1const slot = createSlot("add slot #0");Run2callAdd(slot, 1, 2);3const plan = specialize(slot.state);4callOptimizedAdd(plan, 3, 4);5callOptimizedAdd(plan, "3", "4");

Suppose a test warms up with numbers and then times strings. It measured the switch from one kind of value to another. Sometimes you want exactly that. Most of the time it is an accident. Use the habits from Measuring performance:

• Warm up first.
• Use each result, so the engine can't skip the work.
• Take many timings, not one.
• Report the middle value (the median) or how much the timings vary.

So far, the code was a model. The lesson's tests also run real Node 22, which uses V8 12.4, and check its output. Small details like memory addresses, counts, and exact timing change between versions. So the tests only check short, stable pieces of text.

The programs below use %DebugPrint and %OptimizeFunctionOnNextCall. These are V8 test commands, not JavaScript. They only work when you start Node with the flag --allow-natives-syntax, so these blocks don't run here.

1function add(a, b) {2  return a + b;3}4 5for (let i = 0; i < 30; i += 1) {6  add(i, i + 1);7}8 9%DebugPrint(add);

1Captured on Node 22 (V8 12.4)2- feedback vector: ... [FeedbackVector]3- invocation count: 224- slot #0 BinaryOp BinaryOp:SignedSmall { ... }

1Captured on Node 22 (V8 12.4)2NEVER: feedback metadata is not available in SFI3ONCE: No feedback vector, but we have a closure feedback cell array4MANY: slot #0 BinaryOp BinaryOp:SignedSmall

1function add(a, b) {2  return a + b;3}4 5for (let i = 0; i < 100000; i += 1) {6  add(i, i + 1);7}8 9%OptimizeFunctionOnNextCall(add);10add(1, 2);11add("x", "y");

1$ node --allow-natives-syntax --no-concurrent-recompilation --trace-opt --trace-deopt probe.js   # Node 22 / V8 12.4 capture2[marking ... reason: hot and stable]3[completed compiling ...]4[bailout (kind: deopt-eager, reason: not a Smi): begin. deoptimizing ...]

Here is what this V8 version prints for one add slot, depending on the values it saw:

• Only small whole numbers: BinaryOp:SignedSmall.
• Whole numbers, then one decimal: BinaryOp:Number.
• Booleans or null: NumberOrOddball.
• Only strings: String.
• Small BigInts: BigInt64. Larger BigInts: BigInt.
• A mix of different meanings: Any.

Each button sends one call to the same toy slot. Start with whole numbers, then try strings or BigInts. Watch three things:

• The slot's current state.
• The fast plan that state would allow.
• Whether the guard would let the call you picked use that plan.

1const slot = createSlot("add slot #0");2callAdd(slot, 1, 2);        // small whole numbers: SignedSmall3callAdd(slot, 1.5, 2.25);   // decimals: wider, Number4callAdd(slot, "1", "2");    // strings too: Any

Type feedback is not a reason to write strange code. Most code should be easy to read first. The useful rule is small. It applies only to hot paths: the code that runs most often, which you found by measuring. On those paths, keep the kinds of values and the shapes of objects the same from call to call.

• When you make many similar objects, give them the same properties in the same order.
• If a hot + is meant for numbers, turn text into numbers before the loop, not inside it.
• Don't trust a small speed test until its warm-up values match the real values.
• Keep code easy to read, unless measuring shows a place is hot and its values keep changing kind.

Common misconceptions

Read each row of the table as: "this word means this, and here is the mix-up to avoid."

For each question: find the operation, list the values it saw, and decide whether its fast plan can stay narrow.

Key takeaways

• The code alone doesn't say which kinds of values will come, so the engine watches and writes notes.
• In V8, a step in the bytecode names its slot, like [0]. The slots live in a FeedbackVector, made only once a function has run enough.
• An add slot can say SignedSmall, Number, String, BigInt64, Any, and more. It only gets wider.
• Property and call slots feed inline caches and inlining. Literal slots remember where objects and arrays are made.
• First runs are slow: the engine interprets, makes the vector, fills the slots, and waits before it makes faster code.

Up next: Inline caches, where property and call slots become monomorphic, polymorphic, or megamorphic.