JS Engine and V8 Architecture

Concept

A JavaScript engine is a program that takes your JavaScript source code — plain text — and actually runs it. It does this in three broad steps: parsing the text into a structure it can understand, compiling that structure into something the CPU can execute quickly, and executing it while managing memory as it goes. Google's V8 (used in Chrome and Node.js) is the engine we'll use as the concrete example throughout, since it's the one you're running JavaScript on every single day.

Key Words In Plain English

• JavaScript engine is a program that reads JavaScript text and runs it. V8 (Chrome, Node.js), SpiderMonkey (Firefox) and JavaScriptCore (Safari) are engines.
• Runtime environment is the engine plus the extra tools the host adds, such as timers, fetch, the DOM and the event loop. The host is the browser or Node.js. Difference in one line: the engine runs the language; the runtime adds the things around it.
• Parsing is reading source text and turning it into a structured form. Token is one small piece of the text, such as a keyword, a name or a number. AST (Abstract Syntax Tree) is a tree that shows the structure of the code.
• Interpreter is a program that runs code step by step without first making machine code for all of it. Compiler is a program that translates code into another form, such as machine code. Machine code is the instructions the CPU runs directly. Bytecode is a compact set of instructions for a simple virtual machine. It is smaller and easier to run than source text.
• JIT (Just-In-Time) compilation is compiling code while the program runs, only for the parts that run often.
• Hot code is code that runs many times, so making it faster pays off.
• Optimization is making code run faster by using assumptions, such as “this function always gets numbers”. Deoptimization is throwing away the fast version when an assumption turns out wrong.
• Call stack is the list of function calls running right now. Heap is the large area of memory where objects, arrays and functions are stored.
• Hidden class (shape) is the engine's internal description of an object's property names and their positions. Objects with the same shape share one description. Polymorphic means a piece of code sees a few different shapes. Megamorphic means it sees many.
• Garbage collection (GC) is the engine automatically freeing memory for objects that nothing can reach any more. Reachable means you can get to the object by following references from a root. Root is a starting point for that search, such as a global variable or a variable on the call stack.
• Memory leak is memory your program no longer needs but still keeps, because something still points to it.
• Web API is a feature that the browser provides, not the language, such as setTimeout, fetch and the DOM.

Why This Matters

• It explains why execution contexts, the call stack, and closures behave the way the earlier lessons described — they're not arbitrary rules, they're how the engine is actually built.
• It explains real performance advice you've probably heard without knowing why it's true — like “don't change an object's shape after creating it.”
• It sets up Lesson 14: the event loop isn't part of the JS engine at all — you can't understand where the engine's job ends and the browser's job begins until you've seen the engine's actual boundary.

The Kitchen — An Analogy

The JS Engine vs. The JS Runtime Environment

This distinction matters and is easy to blur: the JS Engine (V8) only contains the parser, compiler/interpreter, the call stack, and the memory heap — the parts that actually understand and run JavaScript syntax. The JS Runtime Environment is the bigger container around it — the engine plus everything the browser (or Node.js) bolts on: Web APIs like setTimeout and fetch (Lesson 5, Lesson 12), the callback queue, the microtask queue, and the event loop that ties it all together (full detail in Lesson 14).

Step 1 — Parsing: Tokens And The AST

let a = 7;

Before anything runs, the engine's parser breaks this line into tokens — let, a, =, 7, ; — the smallest meaningful pieces of syntax. Then it arranges those tokens into an Abstract Syntax Tree (AST): a structured, tree-shaped representation of what the code actually means, roughly like this (this is the common ESTree format that tools show; V8's own internal tree differs in its details):

{
  "type": "VariableDeclaration",
  "declarations": [
    {
      "type": "VariableDeclarator",
      "id": { "type": "Identifier", "name": "a" },
      "init": { "type": "Literal", "value": 7 }
    }
  ],
  "kind": "let"
}

Every later step — interpreting, compiling, optimizing — works off this tree, not the raw text. You can generate an AST for any snippet yourself at astexplorer.net to see this structure firsthand.

Step 2 — Compilation: Why JS Is JIT-Compiled

A common myth is that JavaScript is “just interpreted.” It isn't — modern engines use JIT (Just-In-Time) compilation, which blends two older approaches:

In V8, this plays out as two named components working simultaneously, not one after the other:

• Ignition — the interpreter. It converts the AST into bytecode and starts executing immediately, function by function, with zero delay.
• TurboFan — the optimizing compiler. It watches which functions are called repeatedly (“hot” functions) and, in the background, compiles just those into highly optimized machine code — the “prep sheet” from the kitchen analogy.

Beyond Ignition And TurboFan — The Extra Tiers

Modern V8 doesn't jump straight from “interpreted” to “fully optimized” — it added two intermediate tiers to smooth out the climb, so that mildly-warm functions aren't stuck paying interpreter overhead while waiting to become “hot enough” for full optimization:

The exact thresholds are not call counts. V8 measures how much work a function has done (calls and loop turns) and changes its rules between versions, so treat the table as an order, not as numbers. You don't need to memorize these to understand JavaScript's execution model — Ignition and TurboFan cover the core idea perfectly well. But knowing they exist explains why V8's real-world performance keeps improving version after version without you changing a single line of your own code.

Why Property Access Is Fast — Hidden Classes

JavaScript objects are dynamic — you can add or remove properties at any time. Naively, that should make obj.roomNumber as slow as a hash-table lookup every single time. V8 avoids that with hidden classes (internally called Maps, or “shapes”): whenever you create objects the same way, V8 quietly gives them the same hidden class, recording exactly which properties exist and at what fixed offset — turning property access into a near-instant, direct memory read instead of a lookup.

function makeRoom(number, guest) {
  this.number = number; // same order, every time...
  this.guest = guest;   // ...means every room shares one hidden class
}

const room1 = new makeRoom(305, "A. Sharma");
const room2 = new makeRoom(306, "R. Iyer");
// room1 and room2 share the same hidden class — fast, predictable access

Step 3 — Execution: Heap, Stack, And Orinoco

Execution needs two things you've already met, formally named here: the call stack (Lesson 2) tracks which function is currently running, and the memory heap is the much larger, less organized region where objects, arrays, and functions actually live. As a simple model, small values tied to a running function live on the stack, and anything that needs to outlive a single function call — including the variables a closure holds onto (Lesson 10) — lives in the heap. (Real engines are free to place values differently as an optimization; for example, strings are stored in the heap.)

Garbage Collection, Properly Explained

The heap fills up as your program creates objects, so the engine needs to reclaim memory from objects nothing references anymore. V8's collector is called Orinoco, and it works on a simple observation: most objects die young. So it splits the heap into two generations and treats them very differently:

At its core, Mark-and-Sweep is the idea to hold onto: starting from your program's “roots” (global variables and the variables on the current call stack), then follows every reference from them — including the variables kept by closures that are still reachable —, the collector marks every object it can reach as alive. Everything left unmarked is unreachable garbage — nothing in your code can possibly get to it anymore — and its memory is freed. This is precisely why closures (Lesson 10) can keep a Lexical Environment alive indefinitely: as long as a reachable function still points to it, it's marked “alive” and never swept.

See It Live — Feel The JIT Warm-Up

function square(n) {
  return n * n;
}

console.time("cold run");
for (let i = 0; i < 5_000_000; i++) square(i);
console.timeEnd("cold run");

console.time("warm run");
for (let i = 0; i < 5_000_000; i++) square(i);
console.timeEnd("warm run");

1. Paste this into the console

   Run it in Chrome DevTools or Node.

2. Compare the two timings

   The numbers vary by machine and engine version. The second loop is often a little faster, and sometimes the same, because this function is so small that V8 optimizes it very early, even during the first loop. Run the second loop a third time to see more of the effect.

3. Why

   By the time the first loop finishes, square has been called millions of times — hot enough that V8 has very likely compiled it into optimized machine code. Later runs reap the benefit. Warm-up is real, but for tiny code it is hard to see with a simple timer.

Common Misconceptions

Interview Questions