How the JavaScript Engine Works: JIT, ASTs, and Optimizations

Two objects can produce the same result from the same JavaScript function, yet one call may cause the engine to abandon optimized machine code. The program still behaves correctly. What changed was an assumption the engine made about the objects it expected to receive.

That is the useful reason to learn about abstract syntax trees (ASTs), just-in-time (JIT) compilation, and deoptimization. They explain why execution can have several internal representations, why the runtime collects feedback, and why a sudden change in that feedback can matter.

This article focuses on V8, the engine used by Chrome and Node.js. Other JavaScript engines have their own pipelines and optimization strategies. The worked example uses Node.js to inspect V8, not to claim that a particular coding style will make every application faster.

From source text to executable bytecode

Consider a small function:

function readX(record) {
  return record.x + 1;
}

Before V8 can execute it, the source must be understood and compiled. A simplified path looks like this:

JavaScript source
    |
scanner: tokens
    |
parser: abstract syntax tree (AST)
    |
Ignition bytecode
    |
execution and runtime feedback
    |
optional compilation to machine code

The scanner identifies tokens, including identifiers, punctuation, and operators. The parser uses that input to construct an AST, a structured representation of the program. V8's bytecode compiler then generates instructions for Ignition, its interpreter. Ignition executes bytecode, not the AST directly. V8 describes these stages in its scanner explanation.

The AST is an intermediate compiler representation, not a permanent tree that the interpreter repeatedly walks. Tools such as Babel and AST Explorer also expose ASTs, but their node formats should not be mistaken for V8's private internal representation.

There is also an important startup qualification: V8 does not necessarily fully parse and compile every function when a script loads. It can pre-parse functions and compile them when they are needed. That avoids paying the full cost of code that never runs during the current visit. The V8 team's lazy parsing explanation covers this distinction.

Why V8 has more than one execution tier

An interpreter can get code running without first spending substantial time optimizing it. Frequently executed code, however, may justify the cost of compiling it into native machine instructions.

V8 balances that startup-versus-throughput tradeoff using several tiers:

This is a description of V8's architecture, not a guaranteed four-step journey for each function. A function may remain in bytecode, run as baseline-compiled code, or be optimized. Tiering heuristics and available tiers depend on the engine version, build, configuration, and execution behavior.

The V8 team introduced Sparkplug as a fast baseline compiler and describes Maglev's position between Sparkplug and TurboFan. Compiler implementation details also evolve: V8's 2025 account of the Turboshaft transition is a reminder not to treat one old diagram of TurboFan internals as permanent.

The central JIT idea is that V8 can compile code during execution, using information unavailable from the source text alone. That compilation has a cost. Optimizing a function that runs once may be wasted work; optimizing one that performs substantial repeated work may pay off.

What the optimizer learns from objects

JavaScript allows record.x to work with many different objects. V8 tries to make common cases cheaper by remembering information about property accesses.

An important part of that information is an object's internal map, often described as a hidden class or shape. This is not the JavaScript Map collection. It is engine metadata describing an object's structure.

For example:

const first = { x: 5, y: 10 };
const second = { y: 10, x: 5 };

readX(first);  // 6
readX(second); // 6

Both calls have identical JavaScript semantics. But adding named properties in different orders can produce different V8 maps. Property-access feedback can associate a call site with the shapes it has encountered. An optimizing compiler may use that feedback to generate a fast property read guarded by an expected map.

If a different map arrives, the guard may fail. V8 can deoptimize, reconstruct the state needed to continue execution, and use a less-specialized execution path. It can later collect more feedback and optimize again.

This does not mean every new shape necessarily triggers a bailout, or that objects with differently ordered properties are inherently slow. An access site can handle multiple shapes, and the optimizer may make different decisions based on context. V8's fast properties explanation documents how shapes and property representations make these optimizations possible.

Reproduce an optimization and a deoptimization

The following is a deliberately small engine-inspection exercise, not a performance benchmark. Save it as v8-shape-probe.cjs:

'use strict';

function readX(record) {
  return record.x + 1;
}

const same = { x: 5, y: 10 };
let checksum = 0;

for (let i = 0; i < 100_000; i++) {
  checksum += readX(same);
}

console.log('warmup checksum:', checksum);

const changedShape = process.argv.includes('--changed-shape');
const next = changedShape ? { y: 10, x: 5 } : { x: 5, y: 10 };
console.log('next object:', readX(next));
console.log('original object:', readX(same));

Run it first without tracing:

node v8-shape-probe.cjs
node v8-shape-probe.cjs --changed-shape

Both commands produce the same JavaScript output:

warmup checksum: 600000
next object: 6
original object: 6

The checksum makes the repeated calls observable. It does not measure speed. The default invocation passes an object with the same property order as same. The --changed-shape argument constructs the same properties in the opposite order.

Now compare the two V8 traces:

node --trace-opt --trace-deopt v8-shape-probe.cjs
node --trace-opt --trace-deopt v8-shape-probe.cjs --changed-shape

Observed in a local reproduction: Node.js v22.16.0, bundled V8 12.4.254.21-node.26, optimized readX in both cases. Across three runs of each command, the --changed-shape variant reported wrong map deoptimization for readX, while the same-shape control did not report that particular bailout for readX. The relevant parts of the changed-shape trace were:

[marking ... readX ... for optimization to TURBOFAN ...]
[completed optimizing ... readX ... (target TURBOFAN)]
warmup checksum: 600000
[bailout (... reason: wrong map): begin. deoptimizing ... readX ...]
next object: 6
original object: 6

The omitted addresses, compilation identifiers, and timing details vary by execution. Other functions, including the surrounding loop, may also appear in the trace. Another V8 version or set of tiering decisions may produce a different log or no identical bailout. The input values and observable JavaScript results are the important invariants.

In this run, wrong map means that optimized code encountered an object shape outside an assumption it had made. It does not mean an exception occurred, a JavaScript Map lookup failed, or the function returned the wrong value. The control is useful evidence for this specific V8 build, not proof that matching shapes can never deoptimize or that different shapes must always do so.

Inspect the bytecode, too

To connect the trace back to the earlier compiler pipeline, try:

node --print-bytecode --print-bytecode-filter=readX v8-shape-probe.cjs

With the same Node.js/V8 build, the relevant Ignition instructions included:

GetNamedProperty
AddSmi
Return

These are V8 bytecode instruction names, not JavaScript syntax or stable public APIs. They show that the function has been compiled into operations such as reading x, adding one, and returning. Their exact spelling and layout can change across versions.

To check which flags your installed runtime exposes, run node --v8-options. Node's CLI documentation explains that V8 flags are not stable Node.js APIs. Use them for local investigation, not as production dependencies.

What can and cannot be concluded from the trace

A trace records what the engine did in that run. It is not a timing comparison. The tracing flags themselves add work, and a micro-example does not account for network delays, layout, rendering, garbage collection, or real user interaction.

If a production interface feels slow, start with a user-visible symptom and a performance recording. Only investigate JIT behavior when there is reason to suspect a costly JavaScript execution path. The Chrome DevTools Network and Performance guide covers a broader starting point for browser performance investigations.

When this model should change your code

Three practical distinctions are worth keeping:

1. Stable data shapes can help, but correctness comes first. Predictable object structures may make property accesses easier to specialize. Do not restructure working application code solely to chase a particular trace event without a representative measurement.
2. A deoptimization is a fallback, not a crash. Speculative compilation is designed to preserve the language's observable behavior when an assumption stops holding. Occasional bailouts are not automatically worth fixing.
3. Engine execution is not browser scheduling. An optimized function can still block the main thread if it runs too long. The separate JavaScript event loop guide explains when tasks, microtasks, and rendering opportunities are scheduled.

There are also environments where JIT compilation is restricted or disabled. Node exposes an experimental --jitless option, for example. That is another reason not to describe JIT compilation as a requirement of the JavaScript language.

The useful mental model is parse and compile the needed source, execute it, collect feedback, and sometimes replace an execution path with more specialized code. The engine may later retreat from that specialization without changing what the program means. Knowing how to observe that transition is much more useful than memorizing a list of supposed "JIT-friendly" tricks.