Closures, feedback vectors, and call-site polymorphism

Shared code, private feedback

Why does the same function body sometimes optimise well in one place and stay slow in another? The answer is that each closure instance maintains its own private record of what it has seen at runtime — and that record is what TurboFan compiles against. When you create many instances of the same function — every arrow returned from a factory, every closure pushed in a loop — they do not each carry their own copy of the bytecode. They share one SharedFunctionInfo (SFI): the bytecode, the ScopeInfo, the source metadata. What each closure instance carries separately is its feedback vector: a per-instance array where the engine records the runtime type observations for that instance’s call sites and property accesses.

This split matters for performance. Sharing the SFI keeps memory low and lets the optimiser compile once. The per-instance feedback vector means two closures from the same factory can specialise differently if they are fed different types — and it means a closure only starts collecting useful feedback once that instance has run enough times.

Call sites form inline caches too

You already know property reads form inline caches keyed on hidden class (see the hidden-classes unit’s mono/poly/mega lesson). Calls do the same. A call expression like fn(x) — where fn is a variable or property holding a function — is a call site with its own IC slot in the feedback vector. That slot records which function (which callee identity) has been called here:

• Monomorphic — the site has only ever called one function identity. V8 can speculate hard: it knows the exact target and can inline its body.
• Polymorphic — a small number (up to ~4) of distinct callees. V8 keeps a little table and branches among them.
• Megamorphic — too many distinct callees. V8 stops tracking identities and emits a generic indirect call through whatever fn currently holds.

Why inlining is the whole game

Inlining is the optimisation that unlocks the others. When TurboFan inlines a monomorphic callee into the caller, it can then constant-fold across the boundary, eliminate the call’s argument-passing overhead, and specialise the merged code on the observed types. A megamorphic call site blocks all of that: TurboFan does not know which function will run, so it must emit an indirect call — push arguments, jump through a function pointer, no inlining, no cross-boundary optimisation. On a hot dispatch loop that overhead lands on every iteration.

// Megamorphic: one site, many callee identities.
const registry = { click: onClick, hover: onHover, /* …38 more */ };
function dispatch(type, ev) {
  return registry[type](ev);   // this call site sees dozens of identities -> megamorphic
}

// Monomorphic-friendly: route to a few stable, separately-compiled paths.
function dispatchFast(type, ev) {
  switch (type) {
    case 'click': return onClick(ev);  // each call site has ONE identity
    case 'hover': return onHover(ev);  // monomorphic, inlinable
    default:      return onOther(ev);
  }
}

The switch version has many call sites, each monomorphic, instead of one megamorphic site. Each becomes individually inlinable. The “elegant” single-dispatch version concentrates all the identity variety onto one line and poisons it.

Higher-order functions: keep callbacks uniform

The same effect bites map/filter/reduce and any higher-order helper. A generic helper called with a different callback each time has, internally, one call site (cb(item)) that sees many identities — megamorphic. It still works, but it cannot inline the callback. Patterns that keep it fast:

• Pass the same callback identity when you can, rather than a fresh inline arrow every call. A fresh arr.map(x => f(x)) literal creates a new function identity each call; arr.map(f) reuses one.
• Specialise hot helpers. A truly hot reduction over numbers can be a hand-written loop with the operation inlined, rather than a generic reduce(fn) whose fn(acc, x) site is megamorphic.
• Keep argument shapes uniform too. Even monomorphic-callee sites deopt if the arguments change hidden class wildly; uniform callees and uniform argument shapes both matter.