Browser & Frontend Runtime
V8 internals: multiple-choice review
Crux Multiple-choice synthesis across the V8 unit — hidden-class transitions, IC states, the four JIT tiers, deopt-loops, megamorphic call sites, and Orinoco GC interplay.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one is a decision you make reading a real performance trace — not a definition to recite, but a mechanism to reason about under production load.
Goal
Confirm you can connect hidden-class shape, IC state, tier promotion, deopt behaviour, and GC barriers — the synthesis the individual lessons built toward.
Quiz
Completed
A hot render function ran at 5µs in tests but 250µs in production. A heap snapshot shows objects reaching one property-access site come from 7 distinct constructors. What is the V8-level cause and the real fix?
Heads-up TurboFan cannot be selectively disabled per environment. The function did optimise; its IC degraded to megamorphic because production traffic carries shape diversity the tests never exercised.
Heads-up IC state depends on observed hidden classes, not clock speed. 7 constructors at one site is a megamorphic signature — a 10–50× algorithmic penalty, not a hardware delta.
Heads-up GC affects pause frequency, not the per-call throughput of one function. A 50× per-call slowdown localised to one site is IC degradation, not GC.
Quiz
Completed
Two objects are built as {x:1, y:2} and {y:2, x:1}. A function reads .x on both in a hot loop. What IC state does that access site reach, and why?
Heads-up V8 keys the IC off the hidden class, which records the order properties were added — not just the final set. Different order means different leaf node, hence two shapes.
Heads-up Megamorphic requires 5+ distinct hidden classes at the site. Two shapes is polymorphic — a short branch chain, still fast.
Heads-up V8 tracks the hidden class at every site across all invocations; it transitions uninitialized → monomorphic → polymorphic → megamorphic as shapes accumulate.
Quiz
Completed
Why does V8 ship four JIT tiers (Ignition, Sparkplug, Maglev, TurboFan) instead of one good optimiser?
Heads-up All tiers ship together in one engine and run the same ECMAScript. They differ in the compile-cost-vs-runtime-speed tradeoff, not in language or browser support.
Heads-up JS execution stays single-threaded; tiers are layered optimisation levels, not parallel workers. Concurrent compilation builds the next tier off-thread, but execution is on one tier at a time.
Heads-up Lower tiers exist for startup latency and to gather type feedback, not because TurboFan is unreliable. TurboFan needs the FeedbackVector that Ignition fills before it can specialise well.
Quiz
Completed
A perf-critical function shows repeated 'optimized' then 'deoptimized (not a Smi)' pairs in --trace-deopt within the same second. What is happening, and what is the highest-leverage fix?
Heads-up A one-time deopt during warm-up is normal; a repeating deopt/re-opt pair on the same line every call is a death-spiral that costs more than never optimising.
Heads-up Deopt drops a tier, it does not permanently disable optimisation — the function re-tiers once feedback stabilises. The fix is type-stabilising the input, not a rewrite.
Heads-up Deferring promotion only delays the loop; the guard still fails whenever the value appears. The durable fix removes the pathological value from the hot path, not the optimiser.
Quiz
Completed
Why does Orinoco's concurrent marking need a write barrier, and what breaks without one?
Heads-up Duplicate visits are handled by work-stealing and the grey/black colouring. The write barrier is about the mutator (JS) rewiring references mid-mark, not about thread coordination.
Heads-up The barrier adds ~3–5 cycles per reference write — it is a correctness mechanism, not a speed-up. Parallelism comes from worker threads, not from the barrier.
Heads-up That is the remembered set / card table, a separate mechanism. The write barrier here preserves the tri-color invariant during concurrent old-gen marking.
Quiz
Completed
A numeric-heavy animation loop processing 10M entities per frame keeps drifting off 60fps as it warms up, with deopts on arithmetic and rising minor-GC frequency. Which data layout fixes both the IC and GC problems at once?
Heads-up Varying shapes drive the per-property IC megamorphic (10–50× slower) and allocate a fresh object per entity, raising young-gen GC frequency. This worsens both problems the question names.
Heads-up Map carries hashing and generic-iteration overhead and does not sidestep the IC for value access. For fixed numeric fields in a hot loop it is slower than TypedArrays and still allocates entries.
Heads-up A bigger young gen defers scavenges but does nothing for the megamorphic IC or the Smi-overflow deopts. It treats a symptom; TypedArrays remove both root causes.
Recap
The unit’s through-line is one chain: property-addition order sets the hidden class, the hidden class sets the IC state, the IC state (with type stability) decides whether a function climbs to TurboFan or deopt-loops, and Orinoco’s barriers keep the heap correct while all of this churns. Every production regression in the unit — megamorphic render paths, Smi-overflow deopt-loops, closure leaks into old gen — resolves back to the same lever: stabilise the shape and the numeric type upstream, in the data model, before reaching for any flag.