The Feedback Vector: Where V8 Stores What It Learned

Jay Hubbert — Thu, 22 Oct 2026 15:40:00 +0000

TL;DR: A FeedbackVector is a flat array of tagged slots, one or two words each, that records what the inline caches at each bytecode site learned. The shape of that array is not discovered at runtime - it is computed by the bytecode generator and frozen into a FeedbackMetadata object on the SharedFunctionInfo. The vector is allocated lazily, on the closure’s first execution, and it is owned by a FeedbackCell - so two closures of the same function literal each get their own feedback.

Everything V8 knows about a function at runtime lives in one flat array. When the interpreter executes obj.x, it does not look up x on obj from scratch every time. It looks up a slot in the function’s feedback vector, finds a Map and a handler, and - if the receiver’s map still matches - reads the field straight out of the object.

That array is the FeedbackVector, and it is the single most important data structure in the engine after the Map itself. If you have ever wondered “what does V8 actually remember about my function”, the answer is: this.

The shape of the thing

The layout is declared in Torque, which means it is the authoritative definition - the C++ header just mirrors it:

 cpp
 
 
// src/objects/feedback-vector.tq:34
@cppObjectLayoutDefinition
extern class FeedbackVector extends HeapObject {
 const length: int32;
 invocation_count: int32;
 @if(TAGGED_SIZE_8_BYTES) optional_padding: uint32;
 invocation_count_before_stable: uint8;
 osr_state: FeedbackVectorOsrState;
 flags: FeedbackVectorFlags;
 shared_function_info: SharedFunctionInfo;
 closure_feedback_cell_array: ClosureFeedbackCellArray;
 parent_feedback_cell: FeedbackCell;
 @cppRelaxedLoad @cppRelaxedStore raw_feedback_slots[length]: MaybeObject;
}

The raw_feedback_slots tail is the interesting part: it is a variable-length array of MaybeObject, one entry per feedback slot. The slots are not typed - a slot can hold a Map, a WeakFixedArray of maps, a Name, a Smi, a Symbol sentinel, or a cleared value, depending on what kind of site the slot belongs to.

The osr_state and flags bitfields are packed into single bytes so the interpreter can load them with one instruction. osr_state even has a comment explaining the packing:

 cpp
 
 
// src/objects/feedback-vector.tq:15
@cppScope('FeedbackVector::OsrState')
bitfield struct FeedbackVectorOsrState extends uint8 {
 // The layout is chosen s.t. osr_urgency and
 // maybe_has_(maglev|turbofan)_osr_code can be loaded with a single load
 // (i.e. no masking required).
 osr_urgency: uint32: 3 bit;
 maybe_has_turbofan_osr_code: bool: 1 bit;
 maybe_has_maglev_osr_code: bool: 1 bit;

The slots are allocated at compile time, not at runtime

Here is the part that surprises people. The feedback vector does not grow. Its length is decided when the function’s bytecode is generated, and it never changes afterwards.

The bytecode generator asks for a slot every time it emits a bytecode that has an inline cache:

 cpp
 
 
// src/interpreter/bytecode-generator.cc:4528
 SharedFeedbackSlot element_slot(feedback_spec(),
 FeedbackSlotKind::kStoreInArrayLiteral);

and the request is recorded in a FeedbackVectorSpec, a zone-allocated builder that just appends slot kinds to a vector:

 cpp
 
 
// src/objects/feedback-vector.h:621
 int AddCreateClosureParameterCount(uint16_t parameter_count) {
 create_closure_parameter_counts_.push_back(parameter_count);
 return create_closure_slot_count() - 1;
 }

When the bytecode is finally installed on the SharedFunctionInfo, the spec is frozen into a FeedbackMetadata object - a bit-packed description of the slots, which is what the runtime actually consults to know what a slot means:

 cpp
 
 
// src/codegen/compiler.cc:705
template <typename IsolateT>
void InstallUnoptimizedCode(UnoptimizedCompilationInfo* compilation_info,
 DirectHandle<SharedFunctionInfo> shared_info,
 LocalIsolate* isolate) {
 DCHECK(compilation_info->has_bytecode_array());
 DCHECK(!shared_info->HasBytecodeArray()); // Only compiled once.
 DCHECK(!shared_info->HasFeedbackMetadata());

 DirectHandle<FeedbackMetadata> feedback_metadata =
 FeedbackMetadata::New(isolate, compilation_info->feedback_vector_spec());
 shared_info->set_feedback_metadata(*feedback_metadata, kReleaseStore);

The metadata is tiny. Slot kinds are packed five bits at a time into int32s - six kinds per word - using a BitSetComputer:

 cpp
 
 
// src/objects/feedback-vector.h:861
 using VectorICComputer =
 base::BitSetComputer<FeedbackSlotKind, kFeedbackSlotKindBits,
 kInt32Size * kBitsPerByte, uint32_t>;

with

 cpp
 
 
// src/objects/feedback-vector.h:854
 static const int kFeedbackSlotKindBits = 5;
 static_assert(kFeedbackSlotKindCount <= (1 << kFeedbackSlotKindBits));

Twenty-five kinds, five bits each. A function with 200 inline cache sites needs a metadata object of about 170 bytes, and that object is shared by every closure of the function.

The slot kinds

There are exactly twenty-five real kinds (plus a kInvalid placeholder), and the list is worth reading because it tells you what V8 is willing to learn:

 cpp
 
 
// src/objects/feedback-vector.h:48
enum class FeedbackSlotKind : uint8_t {
 // This kind means that the slot points to the middle of other slot
 // which occupies more than one feedback vector element.
 // There must be no such slots in the system.
 kInvalid,

 // Sloppy kinds come first, for easy language mode testing.
 kStoreGlobalSloppy,
 kSetNamedSloppy,
 kSetKeyedSloppy,
 kLastSloppyKind = kSetKeyedSloppy,

 // Strict and language mode unaware kinds.
 kCall,
 kLoadProperty,
 kLoadGlobalNotInsideTypeof,
 kLoadGlobalInsideTypeof,
 kLoadKeyed,
 kHasKeyed,
 kStoreGlobalStrict,
 kSetNamedStrict,
 kDefineNamedOwn,
 kDefineKeyedOwn,
 kSetKeyedStrict,
 kStoreInArrayLiteral,
 kBinaryOp,
 kCompareOp,
 kDefineKeyedOwnPropertyInLiteral,
 kLiteral,
 kForIn,
 kInstanceOf,
 kTypeOf,
 kCloneObject,
 kStringAddAndInternalize,
 kJumpLoop,

 kLast = kJumpLoop // Always update this if the list above changes.
};

The “sloppy kinds come first” comment is a real design constraint: the language mode of a slot is derived from its kind, by comparing the kind against kLastSloppyKind. GetLanguageModeFromSlotKind does exactly that. So the enum ordering is load-bearing, and reordering it would silently change the semantics of every already-compiled function in the heap.

A slot is one or two words wide. One word for the simple kinds, two for everything that needs a secondary value (a handler, a call count):

 cpp
 
 
// src/objects/feedback-vector-inl.h:103
 case FeedbackSlotKind::kCall:
 case FeedbackSlotKind::kCloneObject:
 case FeedbackSlotKind::kJumpLoop:
 case FeedbackSlotKind::kLoadProperty:
 case FeedbackSlotKind::kLoadGlobalInsideTypeof:
 case FeedbackSlotKind::kLoadGlobalNotInsideTypeof:
 case FeedbackSlotKind::kLoadKeyed:
 case FeedbackSlotKind::kHasKeyed:
 case FeedbackSlotKind::kSetNamedSloppy:
 case FeedbackSlotKind::kSetNamedStrict:
 case FeedbackSlotKind::kDefineNamedOwn:
 case FeedbackSlotKind::kDefineKeyedOwn:
 case FeedbackSlotKind::kStoreGlobalSloppy:
 case FeedbackSlotKind::kStoreGlobalStrict:
 case FeedbackSlotKind::kSetKeyedSloppy:
 case FeedbackSlotKind::kSetKeyedStrict:
 case FeedbackSlotKind::kStoreInArrayLiteral:
 case FeedbackSlotKind::kDefineKeyedOwnPropertyInLiteral:
 case FeedbackSlotKind::kStringAddAndInternalize:
 return 2;

The three sentinels

A slot that has never been written holds the uninitialized sentinel, a root Symbol. A slot that has given up holds the megamorphic sentinel. A third one, MegaDOMSentinel, marks the special case where a DOM accessor has been seen on so many different receiver maps that V8 gave up on the map entirely and installed a “call the generic DOM getter” handler instead.

These symbols are the reason ic_state() is a pure function of the slot contents:

 cpp
 
 
// src/objects/feedback-vector.cc:749
 case FeedbackSlotKind::kLoadProperty:
 case FeedbackSlotKind::kLoadKeyed:
 case FeedbackSlotKind::kHasKeyed: {
 if (feedback == UninitializedSentinel()) {
 return InlineCacheState::UNINITIALIZED;
 }
 if (feedback == MegamorphicSentinel()) {
 return InlineCacheState::MEGAMORPHIC;
 }
 if (feedback == MegaDOMSentinel()) {
 DCHECK(IsLoadICKind(kind()));
 return InlineCacheState::MEGADOM;
 }

The interrupt budget is not in the vector

This is the correction to the mental model most people have. The budget - the counter that decides when a function has run “enough” times to be worth optimizing - does not live in the feedback vector. It lives in the FeedbackCell, next to the vector:

 cpp
 
 
// src/objects/feedback-cell.tq:6
extern class FeedbackCell extends Struct {
 value: Undefined|FeedbackVector|ClosureFeedbackCellArray;
 dispatch_handle: int32;
 interrupt_budget: int32;
}

The value field is a union of three things: undefined (no feedback yet), a FeedbackVector (this closure has feedback), or a ClosureFeedbackCellArray (this function creates closures, and here are their cells).

The budget is measured in bytecodes, not in calls, which is a lovely detail:

 cpp
 
 
// src/execution/tiering-manager.cc:187
int ScaleInterruptBudget(int64_t invocations, int bytecode_length) {
 int64_t budget = invocations * bytecode_length;
 return static_cast<int>(std::clamp<int64_t>(budget, 0, kMaxInterruptBudget));
}

So “four hundred invocations” of a 200-bytecode function buys a budget of 80 000 bytecodes. Every bytecode executed decrements the budget by its own length; when it hits zero, the interpreter interrupts and asks the tiering manager whether to compile. The defaults are invocation_count_for_maglev = 400 (1000 on Android) and invocation_count_for_turbofan = 3000 (see src/flags/flag-definitions.h), so a Maglev-optimized function needs roughly a few hundred calls and a TurboFan one roughly three thousand - but the actual work done is scaled by the function’s size, so a big function is worth optimizing sooner.

Feedback is per-closure, not per-function

This is the subtlety that most people get wrong. The SharedFunctionInfo - the thing that is shared between all closures of one function literal - holds the metadata (the shape of the feedback) but never the values. The values live in a FeedbackVector, and the vector lives in a FeedbackCell, and every closure gets its own cell.

So:

 js
 
 
function makeCounter() {
 let n = 0;
 return { inc: () => n++ };
}
const a = makeCounter();
const b = makeCounter();

a.inc and b.inc are two closures of the same function literal. They have the same SharedFunctionInfo and therefore the same FeedbackMetadata - the same shape of feedback. But they have different FeedbackCells and therefore different FeedbackVectors. If a.inc sees n as a Smi and b.inc sees n as a double, V8 records that separately, and each closure gets its own optimized code.

That is not an accident. It is the difference between “the feedback vector is a property of the code” and “the feedback vector is a property of the instance”. The latter is what makes it safe for V8 to share optimized code aggressively between closures that happen to share a literal.

One closure or many

V8 keeps track of how many closures have been created from a given function literal, and the answer changes the data structure. It is encoded in the map of the feedback cell - three different maps, three different states:

 cpp
 
 
// src/objects/feedback-cell-inl.h:91
FeedbackCell::ClosureCountTransition FeedbackCell::IncrementClosureCount(
 Isolate* isolate) {
 ReadOnlyRoots r(isolate);
 if (map() == r.no_closures_cell_map()) {
 set_map(isolate, r.one_closure_cell_map());
 return kNoneToOne;
 } else if (map() == r.one_closure_cell_map()) {
 set_map(isolate, r.many_closures_cell_map());
 return kOneToMany;
 } else {
 DCHECK(map() == r.many_closures_cell_map());
 return kMany;
 }
}

The transition happens at closure-creation time, in the JSFunction builder:

 cpp
 
 
// src/heap/factory.cc:5301
 // Transition the feedback cell after allocating the JSFunction. This is so
 // that the leap-tiering-relevant one-to-many feedback cell mutation below
 // happens atomically with the closure count increase here, without the
 // object verifier potentially observing a many-closures cell with context
 // specialised code.
 DirectHandle<FeedbackCell> feedback_cell;
 FeedbackCell::ClosureCountTransition cell_transition;
 if (maybe_feedback_cell_.ToHandle(&feedback_cell)) {
 // Track the newly-created closure.
 cell_transition = feedback_cell->IncrementClosureCount(isolate_);
 } else {
 // Fall back to the many_closures_cell.
 feedback_cell = isolate_->factory()->many_closures_cell();

Note the comment: the map transition must be atomic with the closure count increase, or the object verifier could observe a “many closures” cell that still holds context-specialised code.

The one-to-many transition matters because the parent function that creates the closures now has many children, each with its own feedback vector, and the parent needs a place to keep those cells. That place is the ClosureFeedbackCellArray:

 cpp
 
 
// src/objects/feedback-vector.cc:221
DirectHandle<ClosureFeedbackCellArray> ClosureFeedbackCellArray::New(
 Isolate* isolate, DirectHandle<SharedFunctionInfo> shared,
 AllocationType allocation) {
 const int int_length =
 shared->feedback_metadata()->create_closure_slot_count();
 if (int_length == 0) {
 return isolate->factory()->empty_closure_feedback_cell_array();
 }
 DCHECK_GE(int_length, 0);
 const uint32_t length = static_cast<uint32_t>(int_length);

 // Pre-allocate the cells s.t. we can initialize `result` without further
 // allocation.
 DirectHandleVector<FeedbackCell> cells(isolate);
 cells.reserve(length);
 for (uint32_t i = 0; i < length; i++) {
 DirectHandle<FeedbackCell> cell = isolate->factory()->NewNoClosuresCell();
 uint16_t parameter_count =
 shared->feedback_metadata()->GetCreateClosureParameterCount(i);
 auto initial_code = BUILTIN_CODE(isolate, CompileLazy);
 HeapObject::AllocateAndInstallJSDispatchHandle(
 cell, offsetof(FeedbackCell, dispatch_handle_), isolate,
 parameter_count, initial_code);
 cells.push_back(cell);
 }

One cell per CreateClosure bytecode in the parent, each pre-populated with a CompileLazy dispatch entry. The array itself is allocated in the young generation by default - the AllocationType parameter defaults to AllocationType::kYoung.

So the answer to “is the feedback vector shared between closures of the same function literal” is: no, but the cells for the closures that function creates are, and the metadata is.

Allocating the vector

The vector is created lazily. It is allocated when the function is first tiered up to baseline code, which the tiering manager only does after invocation_count_for_feedback_allocation invocations (eight by default). At that point EnsureFeedbackVector fires:

 cpp
 
 
// src/objects/js-function.cc:659
void JSFunction::EnsureFeedbackVector(Isolate* isolate,
 DirectHandle<JSFunction> function,
 IsCompiledScope* compiled_scope) {
 CHECK(compiled_scope->is_compiled());
 DCHECK(function->shared()->HasFeedbackMetadata());
 if (function->has_feedback_vector()) return;

 CreateAndAttachFeedbackVector(isolate, function, compiled_scope);
}

CreateAndAttachFeedbackVector calls EnsureClosureFeedbackCellArray first (which is where the closure-cell array gets built, and where the first budget is set), then FeedbackVector::New, and finally stores the vector back into the cell:

 cpp
 
 
// src/objects/feedback-vector.cc:257
Handle<FeedbackVector> FeedbackVector::New(
 Isolate* isolate, DirectHandle<SharedFunctionInfo> shared,
 DirectHandle<ClosureFeedbackCellArray> closure_feedback_cell_array,
 DirectHandle<FeedbackCell> parent_feedback_cell,
 IsCompiledScope* is_compiled_scope) {

The initialisation loop is where you can see the per-kind defaults. A global IC slot starts cleared (weak), a JumpLoop slot starts cleared with a zero extra, a binary-op slot starts as a zero Smi, and a load IC slot starts as the uninitialized sentinel:

 cpp
 
 
// src/objects/feedback-vector.cc:283
 FeedbackSlotKind kind = feedback_metadata->GetKind(slot);
 int entry_size = FeedbackMetadata::GetSlotSize(kind);

 Tagged<MaybeObject> extra_value = *uninitialized_sentinel;
 switch (kind) {
 case FeedbackSlotKind::kLoadGlobalInsideTypeof:
 case FeedbackSlotKind::kLoadGlobalNotInsideTypeof:
 case FeedbackSlotKind::kStoreGlobalSloppy:
 case FeedbackSlotKind::kStoreGlobalStrict:
 vector->Set(slot, kClearedWeakValue, SKIP_WRITE_BARRIER);
 break;

and the last thing the function does is install the vector into the cell that will own it:

 cpp
 
 
// src/objects/feedback-vector.cc:342
 parent_feedback_cell->set_value(*vector, kReleaseStore);

The kReleaseStore matters. The cell is read by the interpreter on the mutator thread and by the background compiler on a worker thread, so the publication has to be a release store and the reader has to be an acquire load. That is why FeedbackCell::value has two overloads:

 cpp
 
 
// src/objects/feedback-cell-inl.h:34
Tagged<FeedbackCell::Value> FeedbackCell::value() const {
 return value_.load();
}

Tagged<FeedbackCell::Value> FeedbackCell::value(AcquireLoadTag) const {
 return value_.Acquire_Load();
}

The vector is thrown away, not shrunk

When V8 decides a function’s feedback is stale - usually because the code was flushed, see Flushing Code

the cell’s value is reset back to the closure cell array:

 cpp
 
 
// src/objects/feedback-cell-inl.h:67
void FeedbackCell::reset_feedback_vector(
 std::optional<std::function<void(Tagged<HeapObject> object, ObjectSlot slot,
 Tagged<HeapObject> target)>>
 gc_notify_updated_slot) {
 clear_interrupt_budget();
 if (IsUndefined(value()) || IsClosureFeedbackCellArray(value())) return;

 CHECK(IsFeedbackVector(value()));
 Tagged<ClosureFeedbackCellArray> closure_feedback_cell_array =
 Cast<FeedbackVector>(value())->closure_feedback_cell_array();
 set_value(closure_feedback_cell_array, kReleaseStore);

The vector is simply dropped on the floor. There is no “shrink” and no “reuse” - a fresh vector of exactly metadata->slot_count() words will be allocated the next time the function runs, and the metadata guarantees it fits.

Trade-offs

What it buys.

One flat, cache-friendly array. Every inline cache site in a function is one or two words in one contiguous array. The interpreter’s hot path is a single indexed load, and the compiler’s feedback collection is a single pass over the array.
A fixed size, known in advance. Because the metadata is fixed at compile time, the vector can be allocated once, exactly the right size, and never reallocated. There is no “grow the array” path at all.
Per-closure granularity. Because the vector hangs off a per-closure cell, two instances of the same class can learn different things and be optimized differently.

What it costs.

Memory per closure. Every closure that has run a few times owns a FeedbackVector of slot_count words plus a FeedbackCell. For a program that creates millions of closures, that is millions of feedback vectors. V8’s answer is that closures that are never called never get one
- the vector is allocated on first execution, not at closure creation.
Two levels of indirection. To use a slot you need the vector, and to get the vector you need the cell, and the cell is reached through the JSFunction. That is a pointer chase before the actual data.
The metadata is per-SFI but the values are per-closure. If a function is closed over a thousand times, the metadata is computed once and the vectors are computed a thousand times. That is the right trade for precision and the wrong one for memory.

The bottom line

The feedback vector is a flat array whose shape is decided by the compiler. The bytecode generator counts the inline cache sites, the FeedbackVectorSpec records their kinds, and FeedbackMetadata freezes that into a five-bits-per-slot bit-packed object on the SharedFunctionInfo. The runtime then allocates a FeedbackVector of exactly that many words the first time a particular closure runs, and never changes its size.

The mental model to keep is that the metadata is per-function and the values are per-closure. The SharedFunctionInfo says “this function has a load-property slot at index 4 and a call slot at index 5”; the FeedbackVector says “at index 4 the receiver was a JSObject with map 0x… and the field was at offset 24”. The first is shared by every closure of the literal; the second is not.

The thing people get wrong

“The feedback vector belongs to the function.” It belongs to the closure. SharedFunctionInfo holds the metadata; each JSFunction holds a FeedbackCell; the cell holds the vector.

This matters practically. If you write a factory that returns closures and the closures see different shapes, V8 will not share their feedback, will not share their optimized code, and will recompile each one separately. That is by design - it is what lets V8 optimize a closure for the shapes it has actually seen - but it means “one function, one optimized version” is not how V8 thinks. The unit of optimization is the closure, and the feedback vector is the reason why.

Feedback on Opensource internals