Type feedback: the fuel for the optimiser

Why an optimiser is blind without feedback

JavaScript has no static types the engine can trust. At the point function add(a, b) { return a + b; } is compiled, the engine cannot prove a is a number — it could be a string, an object with a valueOf, a BigInt. A naively-compiled + must therefore handle every case: check tags, branch on string-vs-number-vs-object, possibly call a user valueOf, box the result. That generic path is correct but slow.

The way out is speculation: assume the types you have actually observed, emit fast code for exactly those, and protect it with a cheap guard that bails if the assumption breaks (lesson 04). But speculation needs evidence — and the evidence comes from the only tier that runs every operation while watching its operands: Ignition, the interpreter. As Ignition runs, it writes down what it sees at each “interesting” location. That record is the feedback vector.

The feedback vector: structure and ownership

A feedback vector is a fixed-size array allocated in the GC heap. The crucial detail people get wrong is what owns it. The bytecode and the layout of the feedback slots are shared: they live on the function’s SharedFunctionInfo (SFI), the engine’s deduplicated record of “this function’s code”, one per source definition. But the feedback vector itself — the array holding the observed data — is allocated per closure. Two closures created from the same function source share bytecode and slot layout, but each has its own feedback vector, so their runtime observations don’t pollute each other.

Each slot corresponds to one inline cache (IC) site in the bytecode — a place where the type of the operands matters:

• Property access (obj.x, obj.x = v) — records the map (hidden class) of the object seen, plus a handler describing how to load/store at that map.
• Calls (fn(), obj.method()) — records the call target(s) observed, enabling inlining.
• Binary operations (a + b, a < b) — records the type lattice of the operands: were they always Smi (small integer)? Smi-or-HeapNumber? String? Any?
• Element access (arr[i]) — records the elements kind (packed Smi, packed double, holey, dictionary).

The primitive-type lattice

For arithmetic, the feedback is not just “number”. V8 tracks operand types on a small lattice that it widens monotonically as it sees more cases. A useful mental model for a + slot:

None  ->  SignedSmall (Smi)  ->  Number (Smi or HeapNumber)  ->  NumberOrOddball  ->  Any
                       \-> String (if a string operand appears) -> Any

Each new observation can only move up the lattice (widen), never narrow. A slot that has only ever seen small integers stays at SignedSmall, and TurboFan can emit a 32-bit integer add guarded by a single “is Smi” check. The first time that slot sees a value that overflows Smi range, it widens to Number, and the next optimisation emits float64 arithmetic instead. If it ever sees a string, it widens toward Any, and arithmetic falls back to the fully generic routine. This monotonic widening is exactly why mixing types is so corrosive: one off-type value permanently pollutes the slot for the lifetime of that feedback vector.

Garbage in, generic out

Here is the practical question: if you call a hot function with five different object shapes in its first dozen invocations, what does the optimiser see when it finally compiles? The optimiser is only as good as the feedback. Three states matter for any IC slot:

• Monomorphic — one map / one stable type observed. The optimiser specialises hard: direct offset load, inlined call, integer add. Fastest.
• Polymorphic — a small handful (V8’s cap is 4) of maps/types. The optimiser can still inline with an upfront map check that branches between the known cases. Slower, still optimised.
• Megamorphic — more than the cap. The slot is marked with a megamorphic sentinel; the optimiser gives up on specialising it and emits a generic dispatch (a runtime lookup). It may decline to optimise the surrounding function at all.

Together these three states form the whole story: warming with one shape gives you the fast path, letting two or three shapes in still keeps you optimised, but blasting more than four through the same slot permanently degrades it to generic dispatch.

The practical rule that falls out of this: warm a function with consistent types before it tiers up. If a hot function will mostly process integers, do not let the first dozen calls feed it strings; if a call site will mostly receive one object shape, do not route five shapes through it. The feedback vector is filled during the interpreted phase, and whatever lattice and map set it accumulates is exactly what the optimiser will (or won’t) be able to specialise on.