JavaScript-Engine-Modell

Compiler-Stack hinter einer Skriptsprache

JavaScript wirkt wie eine klassische Skriptsprache: kein expliziter Compile-Schritt, kein Type-Annotation-Zwang, dynamisches Typing zur Laufzeit. Genau das täuscht. Eine moderne Engine wie V8 in Chrome, Node.js, Deno und Edge, JavaScriptCore in Safari und Bun oder SpiderMonkey in Firefox ist intern ein mehrstufiger Compiler mit Speculation, Spezialisierung und Rollback-Logik. Der vermeintliche Interpreter ist nur die unterste Stufe.

Die Konsequenz: Performance hängt nicht primär davon ab, wie viele Zeilen du schreibst, sondern wie vorhersagbar dein Code für die Engine ist. Schreibst du eine Funktion, die mal Numbers, mal Strings, mal Objekte bekommt, kann die Engine sie nicht stabil optimieren — sie verfällt in den Bytecode-Modus, wirft generierten Native-Code weg und sammelt neue Profiling-Daten. Dieser Vorgang heißt Deoptimierung und ist in heißen Loops messbar teuer.

Source-Code bis Native-Code in vier Tiers

Die V8-Pipeline besteht aus klar abgegrenzten Stufen. Jede hat ihren eigenen Trade-off zwischen Compile-Zeit und Run-Zeit. Funktionen wandern bei wachsender „Hotness" nach oben.

Source-Code
    │  (Tokenizer + Parser, lazy)
    ▼
AST (Abstract Syntax Tree)
    │  (BytecodeGenerator)
    ▼
Bytecode  ──►  Ignition (Interpreter, sammelt Type-Feedback)
    │              │
    │              ▼  (Funktion wird "warm")
    │          Sparkplug (Baseline-JIT, schnelles Native)
    │              │
    │              ▼  (Funktion wird "hot")
    │          Maglev (Mid-Tier JIT)
    │              │
    │              ▼  (Funktion wird "very hot")
    │          TurboFan (Top-Tier JIT, optimiertes Native)
    │              │
    └──────────────┘  Deopt: zurück zu Ignition

Tokenizer, Parser, Lazy-Parsing

Der erste Schritt ist der Tokenizer (Lexer). Er zerlegt den Source-String in Tokens — Keywords, Identifier, Literals, Punctuation. Der Parser baut daraus einen AST, einen Baum, der die Programmstruktur abbildet. Aus diesem AST generiert V8 später Bytecode.

Ein wichtiges Detail: V8 parst nicht den ganzen Code eager. Lazy Parsing überspringt Funktionsbodies, bis die Funktion tatsächlich aufgerufen wird. Statt der vollen Parser-Arbeit wird nur ein Pre-Parse durchgeführt, der prüft, ob die Syntax valide ist und welche Variablen die Funktion braucht. Das spart bei großen Bundles oft die Hälfte der Startup-Zeit.

// Source:
function add(a, b) { return a + b; }

// AST (vereinfacht):
FunctionDeclaration
    ├── Identifier "add"
    ├── Params: [Identifier "a", Identifier "b"]
    └── Body: Block
            └── ReturnStatement
                    └── BinaryExpression "+"
                            ├── Identifier "a"
                            └── Identifier "b"

Stack-basierter Interpreter mit Type-Feedback

Aus dem AST generiert V8 Bytecode für Ignition, einen registrierungs-basierten (genauer: register-machine mit Akkumulator-Register) Bytecode-Interpreter. Bytecode statt direktem AST-Walk hat zwei Vorteile: Er ist kompakter (gut für Mobile-Memory), und er sammelt Type-Feedback an jeder Call-Site und Property-Access-Stelle.

Type-Feedback ist die Grundlage aller späteren Optimierungen. Jedes Mal, wenn ein Bytecode wie Add ausgeführt wird, notiert sich Ignition: „Hier waren beide Operanden Smi (Small Integer)" oder „Hier war einer ein String". Diese Daten sind später der Treibstoff für TurboFans Speculation.

function add(a, b) { return a + b; }

// Ignition-Bytecode (vereinfacht, --print-bytecode in Node.js):
Ldar  a            // Load argument 'a' in Akkumulator
Add   b, [0]       // Akku += b, Feedback-Slot 0 sammelt Typen
Return             // Akku zurückgeben

// Feedback-Vector nach 100 Aufrufen mit add(3, 4):
// Slot 0: { lhs: Smi, rhs: Smi, result: Smi }  → monomorph
// Tier-Up zu Sparkplug, später Maglev/TurboFan möglich.

Speculation, Spezialisierung und Tier-Up

Wenn eine Funktion oft genug aufgerufen wird (ein interner Counter überschreitet einen Threshold), wird sie „hot". V8 promotet sie nach oben — zuerst zu Sparkplug, dann zu Maglev, dann zu TurboFan. Sparkplug kompiliert den Bytecode 1:1 zu Native, ohne Optimierung; das gibt schon einen ordentlichen Boost, weil der Interpreter-Overhead wegfällt. Maglev und TurboFan spezialisieren den Code anhand des Type-Feedbacks.

Spezialisierung heißt: Die Engine vermutet, dass add(a, b) immer mit Numbers aufgerufen wird, und generiert eine optimierte Version, die nur den Number-Pfad enthält. Vor dem heißen Pfad steht ein Type-Guard, der prüft, ob die Argumente immer noch Numbers sind. Stimmt das, läuft der schnelle Pfad. Stimmt es nicht, springt die Engine in die Deoptimierung: Sie wirft den optimierten Code weg und fällt zurück auf Ignition oder Sparkplug.

Objekte ohne Class-Spec, aber mit interner Struktur

JavaScript-Objekte haben in der Spec keine Klassen — jede Property kann jederzeit hinzugefügt oder entfernt werden. Das wäre für Property-Access katastrophal langsam, wenn die Engine bei jedem Zugriff einen Hashmap-Lookup machen müsste. Lösung: Hidden Classes (V8-Term, in JSC „Structures", in SpiderMonkey „Shapes").

Eine Hidden Class beschreibt das Layout eines Objekts: welche Properties in welcher Reihenfolge an welchem Offset liegen. Zwei Objekte mit gleicher Property-Reihenfolge teilen dieselbe Hidden Class. Property-Access wird dann zu einem direkten Memory-Offset — schnell wie in C.

// GUT: Beide Objekte teilen dieselbe Hidden Class.
function Point(x, y) {
    this.x = x;
    this.y = y;
}
const p1 = new Point(1, 2);
const p2 = new Point(3, 4);
// p1 und p2 haben Hidden Class {x:0, y:1} → Property-Access als Offset.

// SCHLECHT: Unterschiedliche Reihenfolge erzeugt zwei Hidden Classes.
const a = {};
a.x = 1;
a.y = 2;            // Hidden Class A: {x, y}

const b = {};
b.y = 2;
b.x = 1;            // Hidden Class B: {y, x}  — anders!

// Inline-Cache an einer Funktion `getX(p)` wird polymorph:
// mal Hidden Class A, mal B → langsamer Pfad.

Monomorph, polymorph, megamorph

An jeder Property-Access-Site (obj.x, arr[i], fn.call) hängt ein Inline-Cache. Beim ersten Zugriff merkt sich die Engine: „Hier kam ein Objekt mit Hidden Class H1, Property x lag an Offset 12." Beim zweiten Zugriff prüft sie nur noch: „Ist es wieder Hidden Class H1? Ja → direkt Offset 12 lesen." Das ist die Single-Property-Lookup-Variante, monomorph.

Kommen ein paar verschiedene Hidden Classes vorbei (typisch 2–4), wird der Cache polymorph — eine kleine Liste, durch die linear gesucht wird. Über einer Schwelle (in V8 historisch 4) kippt er in megamorph — generischer Hashmap-Lookup mit Pessimisten-Pfad.

// Hot-Function, die in Inline-Caching gut aussieht.
function getX(p) {
    return p.x;
}

// Monomorph: Alle Aufrufe mit gleicher Hidden Class.
for (let i = 0; i < 1_000_000; i++) {
    getX({ x: i, y: i });   // Eine Hidden Class, IC monomorph.
}

// Polymorph: 3 Hidden Classes — IC immer noch ok, aber langsamer.
for (let i = 0; i < 1_000_000; i++) {
    const shapes = [
        { x: i, y: i },
        { y: i, x: i },
        { x: i, y: i, z: i },
    ];
    getX(shapes[i % 3]);
}

// Megamorph: Viele verschiedene Shapes — IC fällt in den Slow-Path.
for (let i = 0; i < 1_000_000; i++) {
    const obj = { x: i };
    obj['k' + i] = i;       // Pro Iteration neue Hidden Class.
    getX(obj);
}

Wenn Speculation fehlschlägt

Deopt passiert, wenn eine Annahme im optimierten Code verletzt wird. Beispiele:

• Eine Funktion wurde mit der Annahme „beide Argumente sind Smi" optimiert — beim 1.000.001sten Aufruf kommt ein String.
• Ein Property-Access wurde monomorph optimiert — plötzlich kommt ein Object mit anderer Hidden Class.
• Eine Property wird per delete entfernt — die Hidden Class wechselt in einen „Slow-Mode" (Dictionary-Mode), ICs werden invalidiert.

Die Engine fängt die Verletzung am Type-Guard, springt aus dem Native-Code zurück in den Bytecode-Frame, sammelt neues Feedback und versucht später erneut zu optimieren. Wiederholte Deopts an derselben Stelle führen dazu, dass V8 die Funktion nicht mehr optimiert — sie bleibt für immer in Sparkplug oder Ignition.

// SCHLECHT: Type-Switch killt die Speculation.
function double(x) {
    return x * 2;
}

// Erste 100k Aufrufe: nur Numbers → TurboFan optimiert für Smi.
for (let i = 0; i < 100_000; i++) double(i);

// Plötzlich ein String — String * 2 → NaN → Deopt.
// Der Native-Code wird invalidiert, neues Feedback gesammelt.
// Aufruf 100_001: deutlich langsamer als die 100k davor.
double('oops');

// GUT: Konsistente Typen.
function doubleNum(x) {
    // Optional: Type-Coercion am Eingang, dann ist der Hot-Path stabil.
    const n = +x;
    return n * 2;
}

Generationaler GC mit Mark-and-Sweep

Der V8-Heap ist in zwei Generationen geteilt: Young Generation (auch „New Space", klein, sehr schneller GC) und Old Generation (groß, seltenerer aber teurerer GC). Hintergrund ist die Generational Hypothesis: Die meisten Objekte sterben jung — temporäre Werte in Funktionen, kurzlebige Closures, Iterator-Frames. Wer das ausnutzt, kann den Common-Case extrem schnell sammeln.

Der Young-GC (Scavenger) kopiert die noch lebenden Objekte aus einem „From-Space" in einen „To-Space" und leert die Quelle komplett. Objekte, die zwei Young-GCs überleben, werden in die Old Generation promoviert. Dort räumt der Old-GC mit Mark-and-Sweep + Mark-and-Compact auf — markiert alles Erreichbare ab den Roots, sammelt den Rest ein, kompaktiert dann den Heap, um Fragmentierung zu vermeiden.

// WeakRef + FinalizationRegistry: ES2021-APIs für GC-Beobachtung.
// Achtung: Beide sind opportunistisch — die Engine GARANTIERT NICHT,
// dass Finalizer laufen. Nur für Caching/Logging-Optimierungen, nie
// für Geschäftslogik (z. B. Datei-Handles freigeben).

const registry = new FinalizationRegistry((label) => {
    console.log('GCed:', label);
});

let big = { data: new Array(1_000_000).fill(0) };
const ref = new WeakRef(big);
registry.register(big, 'big-payload');

big = null;             // letzte starke Reference weg

// Irgendwann später (oder nie):
//   ref.deref()  → undefined, Finalizer feuert mit 'big-payload'

// Faustregel: WeakMap/WeakSet für Caches reichen meistens.
// WeakRef nur, wenn du explizit Reference-Aufbrechen brauchst.

Was die Engine deoptimiert

Drei Patterns, die in der Praxis am häufigsten zu Deopts oder polymorphen ICs führen:

// 1) Property dynamisch hinzufügen → Hidden-Class-Wechsel.
class User {
    constructor(name) {
        this.name = name;
        // 'admin' fehlt hier und wird später dazugesetzt → Hidden Class wechselt.
    }
}
const u = new User('Alex');
u.admin = true;     // Promotion in neue Hidden Class

// FIX: Alle Properties im Constructor initialisieren.
class UserOk {
    constructor(name) {
        this.name = name;
        this.admin = false;     // Slot existiert sofort, kein Wechsel.
    }
}

// 2) arguments-Objekt in Hot-Loops.
function sumLegacy() {
    let s = 0;
    for (let i = 0; i < arguments.length; i++) s += arguments[i];
    return s;
}
// FIX: Rest-Parameter, semantisch sauberer und zuverlässig optimiert.
function sumModern(...nums) {
    let s = 0;
    for (let i = 0; i < nums.length; i++) s += nums[i];
    return s;
}

// 3) with-Statement (in strict mode verboten, in legacy code teuer).
// Verhindert sauberen Scope-Lookup, erzwingt Slow-Path.
// function dont(obj) { with (obj) { return x + y; } }

Wie man der Engine das Optimieren erleichtert

Die meisten Tipps lassen sich auf drei Prinzipien reduzieren: Shape-Stabilität, Type-Stabilität, Inlining-Friendliness.

• Shape-Stabilität: Alle Properties im Constructor (oder direkt im Object-Literal) initialisieren. Reihenfolge konsistent halten. Keine delete-Operationen auf Hot-Path-Objekten.
• Type-Stabilität: Funktionen idealerweise immer mit gleichen Argument-Typen aufrufen. Wenn Mixed-Types unvermeidbar sind, am Eingang explizit casten (+x, String(x)).
• Inlining-Friendliness: Kleine Funktionen schreibt TurboFan eher inline. Riesige Funktionen mit vielen Branches sind schwerer zu spezialisieren. Aufgabe per Funktion, klar geschnitten.

// GUT: Konsistenter Object-Shape, Type-Stabil, kleine Funktion.
class Vec2 {
    constructor(x, y) {
        this.x = +x;        // Coerce am Eingang
        this.y = +y;
        Object.freeze(this); // optional: signalisiert Immutability
    }
}

function dot(a, b) {
    return a.x * b.x + a.y * b.y;
}

// Hot-Loop: TurboFan inlined dot, ICs sind monomorph,
// kein Boxing, kein Type-Guard pro Iteration.
let sum = 0;
const v = new Vec2(1, 2);
const w = new Vec2(3, 4);
for (let i = 0; i < 1_000_000; i++) {
    sum += dot(v, w);
}

Flame-Charts, Heap-Snapshots, V8-Tracing

Konkrete Tools zur Diagnose:

• Chrome DevTools → Performance-Tab: Aufzeichnung erstellen, Flame-Chart inspizieren. Lange Funktions-Blocks im Main-Thread sind Tier-Up-Kandidaten oder Deopt-Anzeichen.
• Chrome DevTools → Memory-Tab: Heap-Snapshots, Allocation-Timeline. Detached DOM-Nodes und Closures-Leaks sieht man hier sofort.
• Node.js: node --prof script.js erzeugt eine V8-Tick-Trace, node --prof-process isolate-*.log macht ein lesbares Profil. Tools wie 0x und clinic.js machen daraus Flame-Graphs.
• V8-Trace-Flags: --trace-opt, --trace-deopt, --print-bytecode — für Engine-Detail-Analyse. Nicht für Production, sehr aufschlussreich für „Warum wird diese Funktion nicht optimiert?".

# V8-interne Optimierungs-Logs (Node.js)
node --trace-opt --trace-deopt script.js

# Bytecode anschauen
node --print-bytecode --print-bytecode-filter=add script.js

# CPU-Profil für clinic.js
npx clinic flame -- node script.js

# Heap-Snapshot programmatisch (Node.js)
node -e "require('v8').writeHeapSnapshot('./heap.heapsnapshot')"

Weiterführende Ressourcen

Externe Quellen

• V8-Blog
• TurboFan-Docs
• Sparkplug — non-optimizing JavaScript compiler
• Maglev — V8's fastest optimizing JIT
• Ignition — Interpreter
• MDN — Memory Management
• Vyacheslav Egorov — mraleph.github.io (V8-Internals-Deep-Dive)
• Petka Antonov — Optimization Killers
• TC39-Proposals (Stage-3-Awareness)

Verwandte Artikel

• Was ist JavaScript?
• ECMAScript-Versionen
• Strict Mode
• Event-Loop im Detail
• Memory und GC
• Hidden Classes und JIT
• this im Detail
• Closures