Fast properties, slow properties, and slack tracking

Three storage modes, three speeds

Why does storage location matter so much? Because a 50-100x cost difference between modes is the kind of cliff that shows up as a flat-line CPU flame chart but disappears in micro-allocations — you only find it by knowing what to look for before profiling.

The DescriptorArray from lesson 01 tells V8 where a field lives. There are three possible answers, in descending speed order:

1. In-object properties. Stored inline in the object’s own memory block, right after the header. Reading one is a single load at a constant offset — the fastest possible. The number of in-object slots is fixed when the Map is created.
2. Out-of-object (“normal”) fast properties. When an object outgrows its in-object slots, further properties spill into a separate PropertyArray that the object points to. These are still fast (fixed-offset, IC-friendly) but cost one extra pointer dereference: load the PropertyArray pointer, then load the slot. The DescriptorArray records a negative-ish index meaning “this field is in the PropertyArray at index N.”
3. Dictionary mode (slow properties). When an object becomes too dynamic — too many properties, or any delete — V8 abandons the fixed-offset layout entirely and switches the object to a NameDictionary: a per-object hash table from property name to value+attributes. Every access is now a generic hash lookup, roughly 50–100 cycles versus ~1 for an in-object load, and the inline cache cannot help. %HasFastProperties(obj) returns false.

// d8 --allow-natives-syntax
const a = { p: 1, q: 2, r: 3 };
%HasFastProperties(a);   // true  — in-object, fixed offsets
delete a.q;
%HasFastProperties(a);   // false — now a NameDictionary, permanently slow

Slack tracking: V8 right-sizes your objects

Here is the self-tuning part the overview skipped. When you define a constructor or class, V8 does not yet know how many properties instances will end up with — this.x = ...; this.y = ... might be followed by more assignments in methods called later. Allocating exactly two in-object slots up front would force a PropertyArray spill the moment a third field appears.

So V8 over-allocates: the initial Map for the constructor reserves extra in-object slots (slack) — more than the constructor’s body declares. As instances are created and run, V8 watches the maximum number of in-object properties they actually use. After enough instances have been allocated (a fixed construction-count threshold), it completes slack tracking: it trims the unused slots, shrinks the instance size in the Map, and finalizes the Map. From then on, every new instance is allocated at the trimmed, exact size.

The consequences for a senior:

• Warm-up instances are larger than steady-state instances. A heap snapshot taken before slack tracking completes overstates per-object size. Measure after warm-up.
• The Map is not “final” immediately. Code that depends on a stabilized shape (and TurboFan’s specialization) only gets it after slack tracking finishes. Microbenchmarks that allocate a handful of objects can see a different shape than production at scale.
• Adding properties outside the constructor after finalization can no longer fit the in-object area and spills to a PropertyArray (or, if dynamic enough, dictionary mode).

What pushes an object into dictionary mode

Dictionary mode is the cliff. You fall off it via:

• delete obj.prop on a fast object — the single most common cause. V8 cannot leave a hole in a fixed-offset layout, so it converts the whole object to a NameDictionary. This is permanent: the object never climbs back to fast properties.
• Too many properties added dynamically (the threshold is large, on the order of many hundreds to ~1000+, and depends on the version), so it is rarely the real culprit — delete is.
• Adding properties in a way that defeats the transition tree — extreme shape churn can cause V8 to give up and switch to dictionary mode to stop allocating Maps.

Note const folding interacts here: when a field is const (only one value ever assigned across instances), V8 can store the value in the Map (in the descriptor) rather than in the object, so reads become “load the constant from the Map” — but the first divergent assignment loses constness (lesson 02) and the value moves into a real field. Dictionary mode abandons all of this.