49. Inside V8: parsing, Ignition bytecode, TurboFan, hidden classes, inline caches

V8's pipeline, from source text to fast machine code:

Source -> Scanner/Parser -> AST -> Ignition (bytecode interpreter)
                                        │
                              runtime profiles hot functions
                                        ▼
                          Sparkplug (fast baseline JIT, no optimization)
                                        │
                              still hot + type-stable?
                                        ▼
                     TurboFan (optimizing JIT: inlining, type
                     specialization, dead code elimination)
                                        │
                        assumption violated at runtime?
                                        ▼
                          DEOPTIMIZATION back to Ignition bytecode

V8 never compiles everything to optimized machine code upfront — that would make page load slow for code that runs once. Instead it starts interpreting immediately (fast startup) and only invests optimization effort in functions proven "hot" by actual runtime execution counts.

Hidden classes (Shapes/Maps internally): V8 doesn't treat JS objects as generic hash maps — it dynamically creates hidden internal "classes" describing an object's shape (which properties, in which order, what types), and objects with the same shape share the same hidden class. This is why adding properties to an object in a consistent order across many instances is measurably faster than adding them inconsistently:

// FAST: both objects get the SAME hidden class (same properties, same order)
function makePointGood(x, y) { return { x, y }; }
const p1 = makePointGood(1, 2);
const p2 = makePointGood(3, 4);   // shares p1's hidden class — V8 can optimize property access

// SLOW: different construction order/shape per object forces V8 to create
// and track SEPARATE hidden classes, defeating this optimization entirely
const p3 = {}; p3.x = 1; p3.y = 2;
const p4 = {}; p4.y = 4; p4.x = 3;   // different insertion order -> different hidden class

Inline caches (ICs): at each property-access call site, V8 remembers which hidden class it last saw and caches the exact memory offset for that property — subsequent calls at the same call site with the same-shaped object skip the lookup entirely ("monomorphic" — fastest). A call site that sees many different shapes ("megamorphic") loses this optimization and falls back to a slower generic lookup — another concrete reason consistent object shapes matter for hot code paths.