Docs
24.1-Engine-Architecture
22.1 Engine Architecture Deep Dive
Understanding how JavaScript engines work internally helps you write more performant code and debug complex issues.
Table of Contents
- •JavaScript Engine Overview
- •The Parser
- •Abstract Syntax Tree (AST)
- •Bytecode Generation
- •The Interpreter
- •JIT Compilation
- •Optimization Pipeline
- •Engine Comparison
JavaScript Engine Overview
A JavaScript engine is a program that executes JavaScript code. Modern engines are highly sophisticated, using multiple techniques to achieve near-native performance.
┌─────────────────────────────────────────────────────────────────────┐
│ JAVASCRIPT ENGINE ARCHITECTURE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Source Code: "function add(a, b) { return a + b; }" │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ PARSING PHASE │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Lexer │ → │ Tokens │ → │ Parser │ → AST │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ COMPILATION PHASE │ │
│ │ ┌───────────────┐ ┌───────────────┐ │ │
│ │ │ Interpreter │ ←────→ │ JIT Compiler │ │ │
│ │ │ (Ignition) │ │ (TurboFan) │ │ │
│ │ └───────────────┘ └───────────────┘ │ │
│ │ ↓ ↓ │ │
│ │ Bytecode Optimized Machine Code │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ EXECUTION PHASE │ │
│ │ CPU executes bytecode or machine code │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Major JavaScript Engines
| Engine | Browser/Runtime | Company | Key Components |
|---|---|---|---|
| V8 | Chrome, Node.js, Deno | Ignition + TurboFan | |
| SpiderMonkey | Firefox | Mozilla | Baseline + IonMonkey |
| JavaScriptCore | Safari | Apple | LLInt + DFG + FTL |
| Chakra | Legacy Edge | Microsoft | SimpleJIT + FullJIT |
The Parser
The parser converts source code text into a structured representation the engine can work with.
Two-Phase Parsing
┌─────────────────────────────────────────────────────────────────────┐
│ PARSING PHASES │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ PHASE 1: LEXICAL ANALYSIS (Tokenization) │
│ ───────────────────────────────────────── │
│ │
│ Source: "let x = 10 + 5;" │
│ │
│ Tokens: │
│ ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┐ │
│ │ let │ x │ = │ 10 │ + │ 5 │ ; │ │
│ ├─────┼─────┼─────┼─────┼─────┼─────┼─────┤ │
│ │ KWD │ ID │ OP │ NUM │ OP │ NUM │ PUN │ │
│ └─────┴─────┴─────┴─────┴─────┴─────┴─────┘ │
│ │
│ PHASE 2: SYNTACTIC ANALYSIS (Parsing) │
│ ───────────────────────────────────────── │
│ │
│ Tokens → Abstract Syntax Tree (AST) │
│ │
└─────────────────────────────────────────────────────────────────────┘
Lazy Parsing (Pre-parsing)
Engines don't parse everything immediately—they use lazy parsing for performance:
// Full parse - executed immediately
function greet() {
console.log('Hello!');
}
greet(); // Called, so fully parsed
// Lazy parse - only pre-parsed initially
function unused() {
// Complex code here...
// Not fully parsed until called
return computeComplexValue();
}
// 'unused' is pre-parsed (syntax checked) but not fully compiled
┌─────────────────────────────────────────────────────────────────────┐
│ LAZY PARSING │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ EAGER PARSING (Full Parse) │
│ • Function is called immediately │
│ • Top-level code │
│ • IIFEs (Immediately Invoked Function Expressions) │
│ │
│ LAZY PARSING (Pre-Parse) │
│ • Inner functions │
│ • Functions not immediately called │
│ • Checks syntax, finds variables │
│ • Doesn't generate AST until needed │
│ │
│ Benefits: │
│ • Faster initial page load │
│ • Lower memory usage │
│ • Parse on demand │
│ │
└─────────────────────────────────────────────────────────────────────┘
Abstract Syntax Tree (AST)
The AST is a tree representation of the source code's structure.
Example AST
// Source code
let sum = a + b;
┌─────────────────────────────────────────────────────────────────────┐
│ ABSTRACT SYNTAX TREE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Program │
│ │ │
│ VariableDeclaration │
│ (kind: "let") │
│ │ │
│ VariableDeclarator │
│ / \ │
│ Identifier BinaryExpression │
│ (name: "sum") (operator: "+") │
│ / \ │
│ Identifier Identifier │
│ (name: "a") (name: "b") │
│ │
└─────────────────────────────────────────────────────────────────────┘
AST Node Types
| Category | Node Types |
|---|---|
| Declarations | VariableDeclaration, FunctionDeclaration, ClassDeclaration |
| Expressions | BinaryExpression, CallExpression, MemberExpression |
| Statements | IfStatement, ForStatement, ReturnStatement |
| Literals | NumericLiteral, StringLiteral, BooleanLiteral |
| Patterns | ObjectPattern, ArrayPattern, RestElement |
AST in Action
// You can explore ASTs with tools like AST Explorer
// or programmatically with parsers
// Example: Simple function
function multiply(x, y) {
return x * y;
}
/*
AST Structure:
{
type: "FunctionDeclaration",
id: { type: "Identifier", name: "multiply" },
params: [
{ type: "Identifier", name: "x" },
{ type: "Identifier", name: "y" }
],
body: {
type: "BlockStatement",
body: [{
type: "ReturnStatement",
argument: {
type: "BinaryExpression",
operator: "*",
left: { type: "Identifier", name: "x" },
right: { type: "Identifier", name: "y" }
}
}]
}
}
*/
Bytecode Generation
After parsing, the interpreter generates bytecode—a low-level, platform-independent representation.
V8 Ignition Bytecode
┌─────────────────────────────────────────────────────────────────────┐
│ BYTECODE GENERATION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ JavaScript: │
│ ────────── │
│ function add(a, b) { │
│ return a + b; │
│ } │
│ │
│ Bytecode (Ignition): │
│ ─────────────────── │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Ldar a1 ; Load argument 'a' into accumulator │ │
│ │ Add a2 ; Add argument 'b' to accumulator │ │
│ │ Return ; Return accumulator value │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ Bytecode Properties: │
│ • Register-based (uses accumulator) │
│ • Compact representation │
│ • Quick to generate │
│ • Portable across architectures │
│ │
└─────────────────────────────────────────────────────────────────────┘
Common Bytecode Instructions
| Instruction | Description | Example |
|---|---|---|
Ldar | Load from register to accumulator | Ldar r0 |
Star | Store accumulator to register | Star r1 |
Add | Add register to accumulator | Add r2 |
LdaSmi | Load small integer | LdaSmi [42] |
Call | Call function | Call r0, r1-r3 |
Return | Return from function | Return |
JumpIfFalse | Conditional jump | JumpIfFalse [offset] |
Viewing Bytecode
// In Node.js, you can view bytecode with:
// node --print-bytecode --print-bytecode-filter=functionName script.js
function example(x) {
if (x > 0) {
return x * 2;
}
return 0;
}
/*
Bytecode for 'example':
LdaZero ; Load 0
Star r0 ; Store in r0
Ldar a0 ; Load argument x
TestGreaterThan r0 ; Compare x > 0
JumpIfFalse [offset] ; Jump if false
Ldar a0 ; Load x
LdaSmi [2] ; Load 2
Mul r0 ; x * 2
Return ; Return result
LdaZero ; Load 0
Return ; Return 0
*/
The Interpreter
The interpreter executes bytecode directly, providing fast startup.
Ignition (V8's Interpreter)
┌─────────────────────────────────────────────────────────────────────┐
│ IGNITION INTERPRETER │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Bytecode Stream │ │
│ │ ┌────┬────┬────┬────┬────┬────┬────┬────┬────┐ │ │
│ │ │Ldar│Star│Add │Ldar│Call│Jump│Ret │... │... │ │ │
│ │ └────┴────┴────┴────┴────┴────┴────┴────┴────┘ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Interpreter Loop │ │
│ │ │ │
│ │ while (hasMoreBytecodes) { │ │
│ │ bytecode = fetchNextBytecode(); │ │
│ │ dispatch(bytecode); // Execute handler │ │
│ │ collectTypeFeedback(); // For optimization │ │
│ │ } │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Type Feedback │ │
│ │ │ │
│ │ "add(1, 2)" → Records: both args are SMI (small integers) │ │
│ │ "obj.x" → Records: obj has shape X, x at offset 8 │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Interpreter vs. Compiler Trade-offs
| Aspect | Interpreter | JIT Compiler |
|---|---|---|
| Startup time | Fast ✓ | Slow (compilation) |
| Execution speed | Slower | Fast ✓ |
| Memory usage | Lower ✓ | Higher (code cache) |
| Best for | Short-running code | Hot loops |
JIT Compilation
Just-In-Time (JIT) compilation converts hot bytecode to optimized machine code.
TurboFan (V8's Optimizing Compiler)
┌─────────────────────────────────────────────────────────────────────┐
│ TURBOFAN OPTIMIZATION PIPELINE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. GRAPH BUILDING │
│ Bytecode → Sea of Nodes (SSA form) │
│ │
│ 2. TYPE INFERENCE │
│ Use type feedback from Ignition │
│ │
│ 3. OPTIMIZATION PHASES │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ • Inlining (inline function calls) │ │
│ │ • Escape Analysis (stack allocate objects) │ │
│ │ • Loop Optimization (unrolling, invariant motion) │ │
│ │ • Dead Code Removal (eliminate unused code) │ │
│ │ • Constant Folding (compute at compile time) │ │
│ │ • Bounds Check Elim (remove redundant checks) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 4. REGISTER ALLOCATION │
│ Map virtual registers to physical CPU registers │
│ │
│ 5. CODE GENERATION │
│ Generate platform-specific machine code (x64, ARM, etc.) │
│ │
└─────────────────────────────────────────────────────────────────────┘
When Does JIT Kick In?
┌─────────────────────────────────────────────────────────────────────┐
│ HOT CODE DETECTION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ V8 tracks function execution: │
│ │
│ function process(data) { │
│ // Called 100 times → still "warm" │
│ // Called 1000+ times → HOT! → Optimize! │
│ } │
│ │
│ Optimization Triggers: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • Loop back-edges (iterations) │ │
│ │ • Function call count │ │
│ │ • Time spent in function │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ Timeline: │
│ ─────────────────────────────────────────────────────────────► │
│ │ │ │
│ │ Ignition │ TurboFan │ │ │
│ │ (interpreted) │ (optimized) │ │ │
│ │ ████████████████ │ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │ │ │
│ │ │ │ │ │
│ │<─── Cold ──────────>│<─────── Hot ──────────>│ │ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Optimization Pipeline
Speculative Optimization
┌─────────────────────────────────────────────────────────────────────┐
│ SPECULATIVE OPTIMIZATION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ function add(a, b) { │
│ return a + b; │
│ } │
│ │
│ // Ignition collects type feedback: │
│ add(1, 2); // a: SMI, b: SMI │
│ add(3, 4); // a: SMI, b: SMI │
│ add(5, 6); // a: SMI, b: SMI │
│ // ... 1000 more calls with integers │
│ │
│ TurboFan ASSUMES: a and b are always integers │
│ │
│ OPTIMIZED CODE: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ ; Skip type checks - we "know" they're integers │ │
│ │ mov eax, [a] │ │
│ │ add eax, [b] ; Direct integer addition │ │
│ │ jo bailout ; But... check for overflow │ │
│ │ ret │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ If assumption is WRONG: │
│ add("hello", "world"); // Strings! Assumption broken! │
│ → DEOPTIMIZATION → Back to Ignition │
│ │
└─────────────────────────────────────────────────────────────────────┘
Deoptimization (Bailout)
┌─────────────────────────────────────────────────────────────────────┐
│ DEOPTIMIZATION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ What triggers deoptimization? │
│ │
│ 1. TYPE CHANGE │
│ function calc(x) { return x * 2; } │
│ calc(5); // Optimized for integers │
│ calc("5"); // String! Deoptimize! │
│ │
│ 2. HIDDEN CLASS CHANGE │
│ function getX(obj) { return obj.x; } │
│ // Optimized for specific object shape │
│ getX({ x: 1, y: 2 }); // Different shape! Deoptimize! │
│ │
│ 3. PROTOTYPE CHANGE │
│ Object.prototype.foo = 42; // Invalidates assumptions │
│ │
│ 4. ARGUMENTS OBJECT │
│ function f() { return arguments; } // Hard to optimize │
│ │
│ Deoptimization is EXPENSIVE: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • Discards optimized code │ │
│ │ • Reconstructs interpreter state │ │
│ │ • May need to re-optimize later │ │
│ │ • Causes performance jank │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Engine Comparison
Compilation Tiers
┌─────────────────────────────────────────────────────────────────────┐
│ ENGINE COMPILATION TIERS │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ V8 (Chrome): │
│ ───────────── │
│ Source → Parser → Ignition (interpreter) → TurboFan (optimizer) │
│ ↓ ↓ │
│ Bytecode Optimized Machine Code │
│ │
│ SpiderMonkey (Firefox): │
│ ───────────────────────── │
│ Source → Parser → Baseline (quick JIT) → IonMonkey (optimizer) │
│ ↓ ↓ │
│ Simple Machine Code Optimized Machine Code │
│ │
│ JavaScriptCore (Safari): │
│ ──────────────────────── │
│ Source → Parser → LLInt → Baseline → DFG → FTL │
│ ↓ ↓ ↓ ↓ │
│ Interp Quick Mid Full Optimization │
│ JIT JIT │
│ │
│ Tier Comparison: │
│ ─────────────── │
│ Speed: Slow ───────────────────────────────────► Fast │
│ Compile: Fast ───────────────────────────────────► Slow │
│ │
│ LLInt/Ignition │ Baseline │ DFG │ TurboFan/IonMonkey/FTL │
│ │
└─────────────────────────────────────────────────────────────────────┘
Key Takeaways
┌─────────────────────────────────────────────────────────────────────┐
│ ENGINE ARCHITECTURE SUMMARY │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. PARSING │
│ • Lexer → Tokens → Parser → AST │
│ • Lazy parsing for unused functions │
│ │
│ 2. BYTECODE │
│ • Intermediate representation │
│ • Fast to generate, portable │
│ • Executed by interpreter │
│ │
│ 3. INTERPRETER │
│ • Executes bytecode directly │
│ • Collects type feedback │
│ • Fast startup │
│ │
│ 4. JIT COMPILER │
│ • Compiles hot code to machine code │
│ • Uses type feedback for speculation │
│ • Much faster execution │
│ │
│ 5. DEOPTIMIZATION │
│ • When assumptions are violated │
│ • Falls back to interpreter │
│ • Avoid by keeping types stable │
│ │
│ WRITE OPTIMIZATION-FRIENDLY CODE: │
│ • Use consistent types │
│ • Initialize object properties in constructors │
│ • Avoid deleting properties │
│ • Avoid changing prototypes │
│ │
└─────────────────────────────────────────────────────────────────────┘
Next Steps
Continue to 22.2 Hidden Classes & Inline Caching to learn how V8 optimizes property access and what makes code fast or slow.