Overview

This PR adds a single line to JSCInitialize in src/bun.js/bindings/ZigGlobalObject.cpp, setting JSC::Options::useEagerCodeBlockJettisonTiming() = true. It follows the exact same pattern as the surrounding option assignments and is placed in the correct block (before JSC::Options::AllowUnfinalizedAccessScope ends and before env-var overrides are applied).

Security risks

None. This toggles a documented JSC GC/JIT timing heuristic; it does not touch auth, crypto, permissions, input parsing, or any attack surface.

Level of scrutiny

The code is trivially correct and needs no scrutiny. The decision it encodes, however, is a global runtime behavior change: shrinking the old-age jettison windows means JSC will discard compiled CodeBlocks sooner, which trades lower steady-state memory for potentially more re-parsing/re-JITing of code that goes briefly cold (e.g., periodic handlers, warm-up paths in long-running servers). That tradeoff is reasonable and may well be the right default for Bun, but it's a product-level tuning call rather than a mechanical fix.

Other factors

• No benchmarks or RSS numbers are included in the PR; the test plan only verifies the flag is set.
• There are no prior reviewer comments to address and no bugs were found.
• Because this affects every Bun process's JIT lifecycle, I'd rather a human maintainer confirm the tradeoff than auto-approve a one-liner whose effect is non-local.

Overview

This PR adds two lines to the JSC options block in JSCInitialize (src/bun.js/bindings/ZigGlobalObject.cpp:298-299): it enables useUnlinkedCodeBlockJettisoning (previously a commented-out = false) and useEagerCodeBlockJettisonTiming. Both make JSC reclaim memory from cold compiled code more aggressively. The author's own inline suggestion to add the useUnlinkedCodeBlockJettisoning line has already been applied and resolved.

Security risks

None. These are JSC GC/JIT tuning booleans with no auth, crypto, input-handling, or attack-surface implications.

Level of scrutiny

The diff is mechanically trivial and follows the exact pattern of the surrounding ~20 option assignments — there's no question the code is correct. However, the effect is a global behavioral change to every Bun process: more aggressive jettisoning trades lower JIT memory residency for potentially more re-compilation of code that goes cold and then warm again. That's a performance tuning judgment call, not a mechanical fix, and it's the kind of change where CI/benchmark results (still pending per the test-plan checklist) and a human maintainer's sign-off are the real review — not line-by-line code inspection.

Other factors

No bugs were found by the bug hunter. The change matches the PR description, builds cleanly per the author, and dumpOptions confirms the flag is set. I'm deferring rather than approving only because runtime-wide engine tuning is outside the "obvious/mechanical" bucket I'm comfortable rubber-stamping.