Inline caches, deeply: feedback slots and handlers

The feedback vector: where ICs actually live

When you see --trace-ic output or a deopt log referencing a “wrong map” or “feedback changed”, you are reading a record of what lives here. Understanding the FeedbackVector is what turns opaque JIT output into a diagnosis.

Each function, once it has run, gets a FeedbackVector — a heap object attached to the function’s closure that holds one or more slots, allocated at compile time, one per IC-bearing operation in the bytecode (each property load, each store, each call, each binary op). The “inline cache” for p.x is not bytes rewritten inside the machine code; it is the contents of that operation’s slot in the FeedbackVector.

This separation matters: the same bytecode can be shared across closures, while the feedback (the observed types and shapes) lives per-FeedbackVector. It is also why the feedback survives tier changes — when Ignition collects feedback and TurboFan later compiles, TurboFan reads exactly these slots. The FeedbackVector is the channel between the interpreter and the optimizing compiler. (We follow that channel forward in 04-the-jit/02-type-feedback.)

A load IC caches {map → handler}

For a property load, a monomorphic IC slot holds two things: the map it expects (the hidden class from lesson 01) and a handler that says how to get the value once the map matches. The fast path is:

load the object's map pointer
compare to the slot's cached map
if equal: apply the handler  -> the value
if not equal: miss -> go to the IC miss runtime, update the slot

The handler is the interesting part. It comes in two broad forms:

• Smi-encoded handler (the common, fast case). For a plain field load on an object with that map, the handler is just a small integer encoding “load the field at in-object index N” (or “PropertyArray index N”). It is a tagged Smi — no separate allocation. Applying it is a single load at the encoded offset. This is the handler behind the “1 MOV” you saw in the overview.
• Handler object (the complex case). When the load is not a plain field read, the handler is a LoadHandler heap object describing a small recipe: call this getter (accessor handler), or walk to the prototype and load there (prototype-chain handler, with a validity cell — lesson 05), or do a dictionary lookup (for dictionary-mode objects), or return a constant from the map. These cost more than a Smi handler but are still far cheaper than a fully generic lookup, because the map check already narrowed the case down.

// Conceptually, for a monomorphic load `p.x` where x is an in-object field at index 0:
//   slot = { map: M_point, handler: Smi(encode(in_object, 0)) }
// For `p.size` where size is a getter:
//   slot = { map: M_point, handler: LoadHandler{ kind: accessor, getter: fn } }

Stores have their own ICs — and they cause transitions

The overview focused on loads. Stores (p.x = v) get their own StoreIC slots, and they are more involved because a store can change the shape. A store IC records not just a map and an offset but, when the store adds a property, the transition to take: “from map M1, adding x with these attributes, go to map M2 and write the value at the new field.” So the store IC is where shape transitions from lesson 02 are actually triggered on the hot path, and where representation generalization (Smi → Double) is detected when the stored value does not fit the field’s current representation.

A store IC also distinguishes “store to an existing field” (just write at the offset) from “store that creates a new field” (take the transition, possibly grow the PropertyArray). A store that flips a field’s representation or constness invalidates optimized code that assumed the old one.

BinaryOp and Compare ICs collect number feedback

Not all ICs are about object shape. Arithmetic and comparison operations have BinaryOpIC and CompareIC slots that record the numeric type history of their operands: have we only ever seen Smis here? Smi and HeapNumber (so, Number)? BigInt? String (for +)? Or a mix (Any)?

This feedback is what lets TurboFan emit unboxed integer arithmetic for a loop counter, or a single floating-point instruction for a Number reduction, instead of a general “add anything to anything” runtime call. A loop that has only ever added Smis builds Smi feedback; the day a value overflows to a HeapNumber, the feedback widens and any code specialized on Smi must deopt (the classic overflow deopt from 02-values-and-memory). So the BinaryOp IC is simultaneously accelerating the interpreter and recording the type profile the JIT will trust.