perf(vm): defer full bytecode generation until payload reuse

[steipete]

What does this PR do?

Repeated node:vm compilations currently generate a separate, recursively compiled tree on the first private-cache hit, even when the original block is still alive. Snapshot the function bodies already generated by execution on that live hit, and defer full generation until an incomplete payload is actually reused after GC.

Record snapshot completeness from the encoder's existing leaf map while GC is deferred, then discard the raw pointer map as before. This covers nested functions and preserves still-lazy decoded bytes. Each entry attempts full promotion at most once. The 256 MiB budget, exact-source/key validation, immutable payload ownership and weak decoded shortcuts stay in place. Public createCachedData/produceCachedData keeps source-based full generation.

How did you verify your code works?

Matched release/LTO builds on one Linux x64 c7a.16xlarge, pinned to eight CPUs with four non-isolated Vitest workers. OpenClaw is frozen at 497de2e869f6a329fac4acc571ed46d6b4454521, baseline Bun at fc53bf8c0fccd0dcbcccfcf75e2c306ab8953cae, paired WebKit at cb8d6f202b5a396caa204ee1bb75d78175aa841a, and Node at 24.21.0. Every process uses fresh private state/cache/tmp directories. Full outcomes, worker policy, zero steal and descendant settlement gate qualified observations.

Workload	Node wall	Baseline wall	New wall	CPU change	Peak RSS change
extension-discord	88.091 s	114.135 s	107.445 s	−7.4%	+1.3%
providers	97.170 s	112.270 s	108.707 s	−3.3%	−0.7%

Discord has three qualified Node/baseline processes and four candidate processes; providers has three per arm. Wall ratios are 0.9414 (95% process-bootstrap interval 0.9402–0.9524) and 0.9683 (0.9627–0.9710). Two Discord controls with CPU-steal ticks remain recorded and excluded; a predeclared balanced round supplies the required qualified counts. RSS is the process maximum; its median passes the +5% gate, but these small samples do not establish a universal memory bound. Bun remains approximately 22% and 12% behind Node on these configs.

Separate native profiles show parse/bytecode CPU falling from 81.3 to 58.6 seconds in Discord (−27.9%) and from 63.5 to 50.3 seconds in providers (−20.7%). Inclusive full-generation cost falls 43.0→21.2 and 25.9→13.4 seconds. Samples are normalized to diagnostic GNU CPU, with roughly 96–97% coverage and no lost events; these profiles are not pooled with ordinary timings. One providers diagnostic with a steal tick was retained and excluded, and its separately named retry qualified.

• macOS and Linux: 1,002 VM/module tests pass, with existing 9 skips and 61 TODOs preserved; fork selectors pass 12/12 and 15/15 rows.
• A parser-trace regression fails baseline and passes the candidate: first live reuse no longer eagerly parses unused bodies. Additional GC-before-reuse, retained-root and late-nested-function guards prevent repeated parsing after promotion; the original complete-function post-GC guard remains unchanged.
• 273 source-position observations match Node. Public cachedData acceptance, caller-buffer mutation isolation, deterministic Bun output and nested sourceURL observations retain baseline behavior.
• The portable benchmark covers short/function-heavy wrappers and Latin1/UTF16 inputs. Independent scoped Codex P2 review is clean. C++ and changed test/docs/benchmark formatting checks pass.

Upstream research found no direct patch for this fork-private cache. oven-sh/bun#40174 concerns the module disk cache; this change requires no engine API or artifact update.

Hosted Linux x64 and macOS arm64 build/test CI passed on exact head 68d3c8b1b0c0fda75778b14d56995c946ad58f65. Formatting, JavaScript lint and source-lints also passed. The ancillary issue-finder could not start analysis because its provider credentials are not configured.