Type feedback & feedback vectors

Engines learn from the values your code actually uses

JavaScript has dynamic values, not static runtime type declarations. An optimizing compiler therefore cannot safely assume that a + b always means small-integer addition just because the first call used numbers. It watches the program run, records what each operation site saw, and later speculates from that evidence.

This lesson sits between tiered compilation and inline caches. We focus on where the evidence lives and how it changes. Later lessons on speculative optimization and deoptimization explain how optimizing compilers consume this feedback and recover when a guess is wrong.

Keep the prerequisites nearby: data types, numbers in depth, type coercion, bytecode and interpreters, and measuring performance.

Feedback starts cold. The interpreter runs bytecode and records what each interesting operation observes. In V8, Ignition collects this information while executing bytecode. TurboFan, Maglev, and inline-cache machinery can later use it, but the first job is just to gather honest evidence from real values.

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 1 creates one empty slot. Lines 7 through 12 classify a single + call. Lines 14 through 18 model the important rule: feedback gets more general, not more specific. The first log is SignedSmall -> int add fast path. The second log widens to Number. The string call makes this same site generic because JavaScript + can mean concatenation too.

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

Notice the site-local part. A different + expression elsewhere in the function would have its own slot and could remain string-only or integer-only. Engines optimize sites, not the entire operator globally.

In V8, the metadata describing which slots a function needs belongs to the shared function information. The runtime feedback itself lives in a FeedbackVector. A modern V8 JSFunction points through a FeedbackCell, which lets V8 delay allocating the full vector until the function becomes hot enough. V8 calls this lazy feedback allocation.

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

The [0] in Add a0, [0] is not an array literal. It is the feedback slot operand for that add bytecode. When the function runs enough, V8 can allocate a feedback vector whose slot 0 records the binary operation hint.

V8's feedback slot kinds include calls, property loads, keyed loads, stores, binary operations, comparisons, literals, for...in, instanceof, typeof, object cloning, string-add-and-internalize, and jump-loop feedback. You do not need to memorize the list, but it explains why feedback is richer than “the type of a variable.”

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

A property load such as user.name records the object maps or shapes it has seen. That feeds the inline-cache states you will study in Inline caches. This lesson names the evidence; the next one names the monomorphic, polymorphic, and megamorphic states in depth.

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

A call slot can record a stable target function and call information. Optimizers use that evidence when deciding whether a call is worth inlining. Literal feedback points at allocation sites or boilerplates, so repeated object and array literals do not start from scratch every time.

A cold function pays setup costs: parsing or compiling bytecode, running in the interpreter, allocating feedback structures lazily, filling slots, and waiting until tiering heuristics decide the function is hot enough. The first few runs are often the least representative runs in a benchmark.

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

The loop does not make add faster by magic. It gives the engine a chance to collect number feedback and, if the function stays hot, compile a plan for the values it actually sees. Warm-up only helps if the warm-up values match the measured workload.

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

If a benchmark warms with numbers and measures strings, it measured a type transition. Sometimes that is exactly the scenario you care about. Most of the time it is accidental noise. Use the benchmarking habits from Measuring performance: warm up, keep results used, run many samples, and report variance or medians.

The lesson tests run child Node processes with Node 22.23.1 and V8 12.4. They assert stable substrings only, because addresses, counts, and exact tiering details can vary. The important facts are visible in release builds: bytecode operands, feedback vectors, slot kinds, lazy allocation messages, and deopt reasons.

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

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

1Node 22.23.1 (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.23.1 (V8 12.4)2[marking ... reason: hot and stable]3[completed compiling ...]4[bailout (kind: deopt-eager, reason: not a Smi): begin. deoptimizing ...]

In this V8 build, an integer-only add site prints BinaryOp:SignedSmall. Adding a double widens it to BinaryOp:Number. Boolean or null operands can produce NumberOrOddball. String-only addition can be String, small BigInts can be BigInt64, larger BigInts can be BigInt, and mixed meanings reach Any.

Use the buttons to feed one toy slot. Start with number pairs, then try strings or BigInts. Watch the current slot state, the specialization it would suggest, and whether the selected call would pass the current guard.

1const slot = createSlot("add slot #0");2callAdd(slot, 1, 2);        // SignedSmall feedback3callAdd(slot, 1.5, 2.25);   // widens to Number4callAdd(slot, "1", "2");    // jumps to Any for this site

Type feedback is not a reason to write strange code. Most application code should be clear first. The practical rule is narrower: on hot paths you have measured, keep value types and object shapes reasonably consistent. Avoid using one function sometimes as a number path, sometimes as a string path, and sometimes as an object-conversion path if it shows up in a profile.

• Initialize the same object fields in the same order when you create many similar objects.
• Keep hot arithmetic sites numeric if they are meant to be numeric; convert at the edge instead of inside the loop.
• Do not trust a microbenchmark until warm-up values match production values.
• Prefer readable code unless profiling shows the site is hot and unstable.

Common misconceptions

Answer by locating the operation site, naming the feedback it saw, and deciding whether the next plan can stay specific.

Key takeaways

• JavaScript engines collect feedback because source text alone does not reveal stable runtime types.
• In V8, bytecode operands point to feedback slots in a lazily allocated FeedbackVector.
• Binary and compare hints include states such as SignedSmall, Number, String, BigInt64, and Any.
• Property and call feedback feed inline caches and inlining decisions; literal feedback can use allocation sites.
• First runs are cold because they interpret, allocate feedback lazily, collect evidence, and wait for tier-up.

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