Compile large closure environments in linear time

[cramforce]

Bun's AOT corpus has a program, classes-and-closures/large-environment.ts (656 KB): one factory declares 8,701 let bindings, and the two methods it returns read and rebind all of them. scriptc took 227 s to compile it, at 777 MB peak RSS. About 46 s went to LLVM IR emission and about 174 s to native code generation. Compile time grew quadratically with the number of captured bindings.

There were two causes. This PR fixes both.

1. Capture analyses ran once per binding over the whole function

Three IR analyses repeated work proportional to the function's size for every captured binding:

• LazyCaptures walked the body again for each capture it checked. It also rebuilt a map of all locals for each capture at each creation site.
• int32-slots walked the declaring function once per box to find the box's initializer.
• CaptureFlow scanned every capture edge, capture list and entry copy once per binding.

Each function's facts are now collected in one walk and indexed: rebound bindings, unchanged parameters, initialized declarations, edges grouped by source, and capture, parameter and entry-copy sets. Hoisted and TDZ initializers are found in one pass. The results do not change: on the baseline compiler's source (503 MB of LLVM), the new compiler's output is byte-identical to the baseline compiler's.

2. LLVM received every box pointer as a value live across the whole function

A captured binding lives in a box. Each box pointer becomes an SSA value that stays live from the binding to its last use, and every one of these values crosses all the calls in between. This happens in the factory and in each method that receives the environment. With thousands of these values, the inliner, instruction selection and greedy register allocation all grow quadratically.

The fix applies to functions holding at least 512 capture boxes (boxed locals plus captures). The self-hosted compiler's largest function holds fewer than 100. Such a function is now emitted with two changes:

• noinline optnone. Nothing is inlined into it, and code generation uses its fast paths.
• Volatile box slots. Loads and stores of its box slots are volatile, so no IR pass promotes them to values. The native helper registers no pass instrumentation, so its IR pipeline would still run mem2reg on optnone bodies.

Each use reloads its box pointer from the frame. Boxes, environments and semantics are unchanged. Only the machine code of those functions is unoptimized.

Results

Linux sandbox, 8 vCPU. Bootstrap CLI, default release build, SCRIPTC_NO_CACHE=1. The generated shape is N number bindings plus N/20 objects and N/20 strings, captured by a reader method and a writer method.

N	before: emit / codegen / wall	after: emit / codegen / wall
500	0.26 / 1.50 / 2.98 s	0.14 / 0.66 / 2.06 s
1,000	0.80 / 3.90 / 6.06 s	0.20 / 1.07 / 2.56 s
2,000	2.34 / 12.5 / 16.6 s	0.32 / 1.65 / 3.58 s
4,000	9.53 / 39.1 / 51.3 s	0.53 / 3.33 / 6.54 s
8,000	48.4 / 160 / 214 s	1.12 / 8.57 / 15.9 s

For large-environment.ts:

• Compile: 226.5 s → 16.4 s.
• Peak RSS: 777 MB → 543 MB.
• Binary: 1.86 MB → 1.89 MB.
• Runtime: 0.18 s before and after, with output identical to Node.

The remaining compile time is mostly tsgo checker requests (about 4 s at 8,000 bindings) and lowering, both close to linear.

A microbenchmark that only calls into 1,050-capture methods (200,000 times bump() plus sum()) runs 6% slower: 0.95 s → 1.01 s. That is the cost of leaving those bodies unoptimized.

Regression checks:

• Self-hosted compiler: the compiler builds itself in 360.6 s before and 357.0 s / 363.6 s after. The binary goes from 54,070,512 B to 54,075,864 B; the difference comes from this PR's added source.
• Runtime suite: bench-runtime --layouts=4 --runs=16, baseline = parent commit. All 31 workloads are neutral, geomean change is -0.1%, and every binary size is unchanged. Ordinary programs emit the same IR.

Tests

• Corpus 5973-large-closure-environment.ts: a 600-binding factory that crosses the threshold. It covers mutation shared across methods, closures created per loop iteration, a nested closure, and a forward-captured read in its TDZ that throws Node's ReferenceError. It runs under Node and compiled: release, dev and sanitized.
• tests/harness/closure-environment-scaling.test.ts: compiles the generated shape at 500 and 4,000 bindings and asserts that post-frontend compile time grows less than 16× for 8× the bindings. Linear growth measures about 5×; the baseline fails at 24.0× (2.4 s → 56.6 s). The test is skipped in the sanitized lane, where uncached builds rebuild the runtime and the fixed cost hides growth.
• Unit tests: cover volatile slot rendering and the optnone threshold in the emitter.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
scriptc	Ready	Preview, v0	Oct 18, 2026 1:24pm UTC