Monomorphic, polymorphic, megamorphic — and the stub cache

The full state machine, not just three words

A load IC slot transitions through more states than the overview implied. The full ladder, one-way toward megamorphic:

• uninitialized — the slot has never run.
• premonomorphic — V8’s “seen once, waiting to confirm” state. The very first execution often records the map here without yet emitting a specialized handler, so a one-shot path does not pay for an IC it will never reuse. The second hit with the same map promotes to monomorphic.
• monomorphic — exactly one map. The slot is {map, handler} (lesson 04). On a hit: load map, compare, apply handler — a couple of instructions. This is the target state.
• polymorphic — 2 to 4 maps. The slot becomes a small list of {map, handler} pairs. A load scans the list (a few compares) and applies the matching handler. Still fast, but the branch chain grows with each shape.
• megamorphic — 5 or more maps. V8 stops tracking maps at this site entirely. The slot is marked megamorphic, and lookups fall through to the megamorphic stub cache.

The megamorphic stub cache: a process-wide hash table

This is the part the overview never mentions. When a site is megamorphic, V8 does not do a fresh property search on every access. Instead it consults a single, global (per-isolate) hash table — the megamorphic stub cache — keyed by (map, property name) and storing the handler. The access becomes:

1. Compute a hash from the object’s map and the property name.
2. Probe the stub cache (it is a small, fixed-size open-addressed table — primary and secondary tables).
3. On a hit, use the cached handler. On a miss, do the full runtime lookup and insert the result.

So a megamorphic site is a hash probe plus a likely handler application — much slower than a monomorphic compare-and-load (tens to low hundreds of cycles vs ~1), and because the table is shared and fixed-size, different megamorphic sites evict each other’s entries. The cost is not just the probe; it is that the site can no longer be specialized.

Why megamorphic is JIT-hostile, not just slower

The deeper cost is what it does to TurboFan. A monomorphic or low-polymorphic site gives the optimizer a small, known set of shapes, so it can inline the field load (or the whole method) and guard with a cheap map check. A megamorphic site gives TurboFan no usable shape information — the feedback is “anything” — so TurboFan must emit a generic call to the IC stub-cache machinery and cannot inline the access or anything reachable through it. One megamorphic property access in a hot inlined method can therefore block a whole chain of optimizations, costing far more than the per-access hash probe alone.

Prototype-chain ICs and validity cells

Many real loads do not find the property on the object itself but on its prototype (methods live on Class.prototype). A prototype-chain IC caches “the property is N levels up the chain, at this offset” — but that is only safe while the prototype chain has not changed. V8 guards it with a validity cell: a small heap cell, shared by the maps that depend on a given prototype, that is “valid” until someone mutates that prototype (adds/removes a property on it, or reassigns it). A prototype IC’s fast path is: check map, check the validity cell is still valid, then load.

The teeth: mutating a prototype after objects exist invalidates the validity cell, which deoptimizes every IC and every TurboFan-compiled function that relied on it. This is why monkey-patching Array.prototype or assigning to SomeClass.prototype.method at runtime (after the hot paths warmed up) can cause a sudden, global-feeling slowdown — you tripped a validity cell that thousands of sites trusted.