What Runs Your Code

None of them. JavaScript is ECMAScript: a language specification that defines syntax, the type system, objects and prototypes, functions, promises and the job queue, the built-in library (Object, Array, Map, JSON, Math...), and the semantics of running a script or module. An engine implements that. Everything else your program touches is the host: the thing that embedded the engine and gave it a world to act in.

A JavaScript engine has the same four jobs as any language runtime: parse, compile, execute, manage memory. What makes JavaScript's version hard is the language's dynamism, and every piece of machinery in the next twelve parts exists to make a dynamic language run as if it were static.

the whole course in one sentence:

  the engine is a compiler that guesses; fast JavaScript is JavaScript whose guesses stay true.

  monomorphic property access   → the guess "this is always shape A" holds
  consistent number types       → the guess "this is always a small integer" holds
  stable prototypes             → the guess "this method is always that function" holds
  no eval, no arguments leaks    → the guesses are allowed at all

V8's pipeline has five stages and four tiers. Source goes through a scanner and parser to an AST; the AST is compiled to Ignition bytecode and interpreted; hot bytecode is compiled by Sparkplug, Maglev and TurboFan to successively better machine code; and any tier can deoptimise back to the interpreter. Each later part is one box of this figure opened up.

Follow one function through ten thousand calls. The pattern is the same for every function the engine ever sees; only the thresholds vary.

a small experiment:

  function add(a, b) { return a + b }
  for (let i = 0; i < 1e5; i++) add(i, 1);         // integers: optimised for Smi add
  add('x', 'y');                                        // strings: the guess fails

  $ node --trace-opt --trace-deopt add.js
  [marking 0x... <JSFunction add> for optimization to MAGLEV, reason: hot and stable]
  [compiling method 0x... <JSFunction add> (target MAGLEV)]
  [marking ... for optimization to TURBOFAN, reason: hot and stable]
  [bailout (kind: deopt-eager, reason: not a Smi): begin ... <JSFunction add>]

"reason: not a Smi" is the engine telling you which guess you broke.

For a page or a server process, the engine's cost before any of your code runs is parse plus compile plus the top-level execution of every script. This chapter is the accounting; part 1 is the parser itself.

V8's units of memory and execution are the isolate and the context. Every memory limit, every GC pause, every "JavaScript is single-threaded" statement is about an isolate. Every "the global object" and "instanceof fails across frames" is about a context.

The event loop is not in the engine. What the engine has is a job queue (what the HTML spec calls the microtask queue) and a rule: after any script or callback runs to completion, drain the queue before returning to the host. The host owns the outer loop: which task runs next, when rendering happens, how timers and I/O are delivered.

one task, in a browser and in Node:

  setTimeout(() => log('timeout'), 0);
  Promise.resolve().then(() => log('micro 1'));
  queueMicrotask(() => log('micro 2'));
  (async () => { log('async start'); await null; log('after await') })();
  log('sync end');

  everywhere: sync end? no:  async start · sync end · micro 1 · micro 2 · after await · timeout

  Node only, if you add process.nextTick(() => log('tick')):  tick runs before micro 1. that queue is Node's, not V8's.

Every claim in this module can be checked. The engine ships its own shell and dozens of tracing flags; Node exposes them; DevTools visualises the results. Learn the five commands below and you can verify anything in the next fourteen parts.