How V8 Implements JavaScript Closures

For front‑end developers, closures are encountered constantly, for example in React Hooks to capture component state, in Vue to define computed properties and watchers, and in Angular to create services and perform dependency injection.

Understanding the reasons and mechanisms behind closures is therefore crucial for everyday development.

Why JavaScript Can Create Closures

JavaScript’s language design makes closures inevitable:

Functions can be defined inside other functions.

Lexical scoping ( 词法作用域 ) allows inner functions to access variables of their outer functions.

Functions are first‑class citizens and can be returned as values.

A classic closure example that runs through the whole article is:

function multi() {
    var a = 10;
    return function inner() {
        return a * 10;
    }
}
const p = multi();

This code declares multi , creates a local variable a , returns an inner function that references a , and finally stores the inner function in p . The inner function retains access to a even after multi finishes, because a closure is formed.

How V8 Executes JavaScript

V8 compiles JavaScript to an intermediate bytecode before execution. It uses a hybrid strategy that combines interpretation and just‑in‑time (JIT) compilation:

Interpretation: source code is parsed into an abstract syntax tree (AST) and executed by an interpreter for fast startup.

Compilation: hot code paths are compiled to optimized machine code for better runtime performance.

The overall flow is:

Initialize the execution environment (heap, stack, event loop, etc.).

Parse the source to generate an AST and scope information.

Generate bytecode from the AST.

Interpret the bytecode.

When hot code is detected, compile it to native code.

If a hot function cools down, de‑optimize it back to bytecode.

Lazy Parsing and Closures

V8 does not parse every function eagerly. It employs lazy parsing – functions are parsed only when they are actually executed. This saves startup time and memory, especially on mobile devices.

When a function contains a closure, V8 must still know whether the inner function accesses variables from the outer scope. The parser therefore performs a quick preparser pass on top‑level functions to detect syntax errors and to record any external variable references.

Using the D8 tool, we can inspect the AST of a simple function:

var top = 1;
function multi(a) {
    return a * 10;
}

Running d8 --print-ast yields an AST that shows a variable declaration for top and a function declaration for multi . Notice that the body of multi is not parsed until the function is actually called.

When the function is finally executed, V8 generates a new AST and bytecode for it, as shown by d8 --print-bytecode :

[generated bytecode for function: multi]
Bytecode length: 14
Parameter count 1
Register count 1
Frame size 8
Bytecode age: 0
0x6d30025a092 @ 0 : 83 00 01 CreateFunctionContext [0], [1]
0x6d30025a095 @ 3 : 1a fa PushContext r0
0x6d30025a097 @ 5 : 0d 0a LdaSmi [10]
0x6d30025a099 @ 7 : 25 02 StaCurrentContextSlot [2]
0x6d30025a09b @ 9 : 80 01 00 02 CreateClosure [1], [0], #2
0x6d30025a09f @13 : a9 Return

The bytecode shows how V8 creates a function context, loads the constant 10 , stores it in the current context, creates the closure, and finally returns.

Pre‑parser Role

The pre‑parser solves two problems caused by lazy parsing combined with closures:

When a function finishes, its execution context is destroyed, but any variables captured by a closure must stay alive. The pre‑parser copies those captured variables from the stack to the heap.

Before a lazily parsed function is executed, the pre‑parser cannot know whether it will capture outer variables. It therefore performs a quick scan; if external references are found, it records them so that the later full parse can generate the appropriate closure.

In addition, the pre‑parser now correctly handles duplicate variable declarations, aligning with the ECMAScript specification.

Summary

This article explained how V8 implements JavaScript closures. V8 uses lazy parsing to speed up startup, but lazy parsing conflicts with closures because the engine must know which outer variables are captured. The pre‑parser bridges this gap by quickly scanning functions, copying captured variables to the heap, and ensuring that later bytecode generation can access them efficiently.

Developers should also be aware of the memory‑leak risk of closures: retaining references to large objects or DOM nodes inside a closure can prevent those objects from being garbage‑collected. Extract only the needed values into separate variables to mitigate leaks.