From first principles: how a .js file in your editor becomes bytes the CPU executes.

SECTION 15Memory: the heap, the stack, GC

C makes you manage memory. JavaScript does not. The cost of "does not" is a sophisticated runtime that constantly allocates, tracks, and reclaims memory.

15.1 The V8 heap layout

15.2 Allocation: the bump allocator

For:

const obj = { x: 1, y: 2 };

Allocation in young gen is just:

free_top = young_gen.top
new_obj  = free_top
young_gen.top += sizeof(JSObject)   ; bump
if (young_gen.top > young_gen.limit)
  trigger_scavenger()

A single increment plus a limit check. Allocating millions of short-lived objects per second is ordinary.

15.3 Scavenger: collecting young gen

The young generation is split in half: from-space and to-space. Allocations only happen in from-space. When from-space fills up:

Cost is proportional to live data, not total allocations. Garbage doesn't get touched.

Objects that survive two scavenges get promoted to the old generation (different copy destination, same algorithm during that one cycle).

15.4 The remembered set: tracking old → young pointers

Problem: the scavenger only walks young gen. But what if an old-gen object holds a pointer to a young-gen object? We can't miss that root.

Solution: a remembered set, a side-table of "locations in old gen that point into young gen."

When JS code writes a pointer into an old-gen object's field, the engine inserts a check:

void WritePointerField(HeapObject* obj, int offset, HeapObject* value) {
  obj->RawWriteField(offset, value);

  if (InOldGen(obj) && InYoungGen(value)) {
    AddToRememberedSet(obj, offset);
  }
}

This write barrier runs on every pointer write. The implementation is heavily optimized — typically a few instructions checking memory page bits — but it's never zero cost.

During scavenger GC, the remembered set is walked as additional roots. We don't have to scan all of old gen. That's the whole reason generational GC works.

15.5 Mark-compact: collecting old gen

Old gen objects tend to live a long time. Copying them all every cycle would be wasteful. So old gen uses mark-compact instead.

15.6 Incremental and concurrent marking

A naive mark phase pauses JS execution for the entire walk. For a 1GB heap that can be hundreds of milliseconds — a janky disaster.

V8 marks incrementally: do a few milliseconds of marking, run JS for a while, mark more. And concurrently: do marking on a background thread.

This sounds simple but introduces a problem: while marking is paused, JS code might mutate the heap. Specifically, JS might:

1. Read pointer from BLACK object (already marked)
2. Write that pointer into a WHITE object (not yet marked)
3. Remove the pointer from the BLACK object
4. Now the WHITE object is unreachable from anywhere we'll visit
   → GC will incorrectly think it's garbage

This violates the tri-color invariant: a BLACK object now points to a WHITE object.

Solution: another write barrier. Every pointer write during marking:

void WritePointerField(HeapObject* obj, int offset, HeapObject* value) {
  obj->RawWriteField(offset, value);

  // Generational barrier (as before)
  if (InOldGen(obj) && InYoungGen(value)) {
    AddToRememberedSet(obj, offset);
  }

  // Incremental marking barrier
  if (marking_active && IsBlack(obj) && IsWhite(value)) {
    MakeGrey(value);
    PushToMarkingQueue(value);
  }
}

Now incremental/concurrent marking is safe. JS pays a tiny cost on every pointer write, in exchange for not having multi-hundred-millisecond GC pauses.

This is the deep reason React advice like "use stable references with useMemo/useCallback" matters. Every fresh closure or array allocated on every render is GC pressure.

15.7 The call stack

When optimized JS calls a function, it uses the native CPU stack with standard call/ret. The stack frame contains:

• The return address
• Saved frame pointer (rbp)
• Saved registers (caller-saved by convention)
• Local variables that didn't fit in registers
• A "frame type marker" so the GC knows whether this is a JS frame, an interpreter frame, or a C++ frame

The GC walks frames during collection to find roots. It needs to know which slots in each frame hold tagged pointers (so they can be visited and updated) versus raw values (so they're left alone). For optimized code, V8 stores this metadata as a side-table per code object.

For the interpreter, V8 maintains a parallel "interpreter stack" within the heap. Each bytecode invocation has an InterpreterFrame holding the registers, accumulator, bytecode array pointer, etc. This is what powers the call stack you see in DevTools when you're not optimized.

SECTION 16The event loop

The engine doesn't drive the program. The host environment does.

while (alive) {
  task = macrotask_queue.pop()
  if (task) execute_to_completion(task)

  while (microtask_queue.not_empty()) {
    mt = microtask_queue.pop()
    execute_to_completion(mt)
  }

  // browser only: render frame, idle work
}

await is a microtask scheduling mechanism. setTimeout(fn, 0) is a macrotask. They are different queues with different priority — and that's why await continuations run before setTimeout(0) callbacks even though both are "as soon as possible."

SECTION 17End-to-end: console.log("Hello") from text to terminal

Putting everything together for one line.

17.1 The text on disk

console.log("Hello");

UTF-8 bytes:

17.2 V8 starts up (already done before your file is read)

• Isolate created
• Snapshot deserialized: console, Object, Array, all builtins ready
• Default Context exists with global object
• Builtin code (including console.log) sits in code space, ready to call

17.3 Host loads source

Node calls libuv to read main.js synchronously, gets a Buffer, hands the UTF-8 bytes to V8.

17.4 Scanning + parsing

Tokens: [IDENT:console] [DOT] [IDENT:log] [LPAREN] [STRING:"Hello"] [RPAREN] [SEMI]

AST: ExpressionStatement
       └── CallExpression
             ├── callee: MemberExpression(console.log)
             └── args: [StringLiteral("Hello")]

The string "Hello" becomes a heap-allocated String object. Its contents in memory:

17.5 Bytecode

For the wrapping function (modules become functions internally):

21 00 00       LdaGlobal "console", fb=0
c8             Star1
2f f8 01 02    GetNamedProperty r1, "log", fb=2
c9             Star0
13 02          LdaConstant "Hello"
c7             Star2
61 f9 f8 f7 04 CallProperty1 r0, r1, r2, fb=4
0e             LdaUndefined
ae             Return

Constant pool: ["console", "log", "Hello"].

17.6 First execution (Ignition)

Ignition's threaded interpreter executes:

LdaGlobal:
  - Look up "console" in the global object
  - Found: a JSObject (the console builtin)
  - rax ← console
  - feedback slot 0 records: "found at this property cell"

Star1:
  - r1 ← rax (console)

GetNamedProperty:
  - r1 = console (a JSObject with a hidden class)
  - Look up "log" on console
  - Found: a JSFunction whose code points to V8's builtin console.log
  - rax ← log function
  - feedback slot 2 records: shape of console + offset of log

Star0:
  - r0 ← rax (log function)

LdaConstant:
  - rax ← constant_pool[2] = "Hello" String object pointer

Star2:
  - r2 ← rax

CallProperty1:
  - Set up JS call:
    rdi = r0 (the function)
    rsi = current Context
    rdx = undefined (not new.target)
    rax = 1 (one argument)
    push receiver (r1, console)
    push arg (r2, "Hello")
  - call <log function's code>
  - feedback slot 4 records: function = the console.log builtin

Inside console.log (compiled C++/Torque code):
  - Validate arguments
  - Format "Hello" for output (via Node's Console implementation)
  - Eventually calls process.stdout.write("Hello\n")
  - Which calls libuv's uv_write
  - Which calls the write(2) syscall

write(1, "Hello\n", 6)

The OS:
  - Receives the syscall
  - Routes 6 bytes to file descriptor 1 (stdout)
  - Bytes appear on terminal

LdaUndefined:
  - rax ← undefined

Return:
  - Standard function return

17.7 If this is in a hot loop

After Ignition has executed it a few thousand times with stable types:

1. Sparkplug compiles the bytecode 1:1 to machine code, removing dispatch overhead
2. Maglev may inline the property accesses based on feedback
3. TurboFan can inline console.log itself if its identity is stable, fold "Hello" as a constant, and emit:

; Speculative checks (one per assumption):
cmp [global_console_cell], <cached_console>     ; console hasn't been replaced
jne deopt
cmp [console_map], <cached_console_map>         ; shape unchanged
jne deopt

; Direct call to builtin
mov rdi, <cached_log_function>
mov rsi, <cached_context>
mov rax, 1
push <cached_console>             ; receiver
push <cached_hello_string>        ; argument
call <log_builtin_address>

Now we're at C-like speed: a few register loads, a call, and we're in the builtin. Three or four CPU cycles of overhead instead of dozens.

17.8 The bytes finally hit the OS

Either way — interpreter or optimized — the path bottoms out at write(1, "Hello\n", 6):

Below that syscall, it's the same OS-level path the C document covered.

SECTION 18Memory layout vs C: side-by-side

SECTION 19What the engine does NOT do

The engine does not:

• Type-check your code in any language sense (no int x = "hello" rejection)
• Tell you about logic bugs
• Care what file your code came from
• Distinguish TypeScript from JavaScript (TS is gone before the engine sees it)
• Know about your bundler, your framework, your build chain

The engine does:

• Parse, interpret, compile, optimize, deoptimize, GC
• Watch your runtime behavior and adapt
• Throw runtime errors when operations fail (undefined is not a function)

The host does:

• Fetch sources (HTTP, fs)
• Provide APIs (DOM, fetch, fs, setTimeout, console)
• Drive the event loop
• Manage threads (web workers, worker_threads)

SECTION 20The shortest accurate version

JS source text bytes
  → tokens
  → AST
  → BytecodeArray + FeedbackVector
  → interpreted by Ignition's threaded interpreter (collecting type feedback)
  → Sparkplug machine code (warm)
  → Maglev machine code (hot)
  → TurboFan machine code (very hot)
  → CPU executes
  → possibly deoptimized back to bytecode
  → repeat

Throughout, the GC manages memory generationally with write barriers,
the event loop schedules tasks and microtasks,
and modules link statically (ESM) or via require calls (CJS).

The engine is a compiler, an interpreter, a profiler, an optimizer, a deoptimizer, a memory manager, an event-loop participant, and a host of pre-built built-ins — all working together so that this:

console.log("Hello");

eventually becomes the same six bytes hitting write() that a C program would produce.

Just by a much, much longer road.