fix: clear dead stack before asynchronous GC requests - #209

A parked worker can finish its immediate GC wake and collection while an unreachable object remains live, so its finalizer never runs. This extends Bun's existing stack-clearing boundary from synchronous GC to ordinary and idle asynchronous GC requests.

The regression follows the engine upgrade in upstream commit 5c6d4e24cd185d5bef8d98e7f1f1e3ef10ac163f (oven-sh/bun#46279), carried by the fork's upstream sync. That commit added clearStackBelowCaller to synchronous JSC__VM__runGC; Bun.gc(false) bypasses it. Traces show publication, owner wake, libuv delivery, timer firing and GC completion all occur. Finalizer enqueue is the missing outcome. The exact engine commit and historical retaining stack slot are still unknown.

Clearing now happens at JSC__VM__collectAsync and JSC__VM__collectAsyncIdle, immediately before the request enters JSC. The idle no-work return remains before clearing. Timer dispatch, collector polling and the original test are unchanged. The helper preserves its 2 KB release / 16 KB ASAN-and-assert range and non-inlining boundary.

The helper uses platform bulk zeroing and a pointer-bearing compiler barrier. The pointer operand matters: Clang can discard writes to an unescaped local array despite a memory clobber. An earlier attempt compiled to an empty helper and failed the original Windows ARM64 test. Actual Linux and macOS portable/profile text sections are identical. Their helper disassembly retains a 2,048-byte memset/bzero call, and both async entry points retain the helper call.

Native diagnosis: 80 trials

Ten interleaved trials per executable, using the original test and its original deadline:

Engine crossover and same-executable toggle. All 80 trial logs, executable identities/hashes and engine/adapter hashes were checked. Diagnostic PR #206 is closed unmerged. Linux's original S8/S7 comparison passed ten runs each, so this lane did not reproduce the release regression on Linux; earlier sync qualification did observe Linux failures.

Functional proof passes; cost accepted as a documented exception

Head 3f65cff0d2c2fbdae7921634fa0724c633c8b6bd is ready to merge. The macOS GC-loop cost exceeds its predeclared 1.02 limit, and maintainers accepted it as a documented exception: an asynchronous GC request may cost up to +50 ns on macOS and up to +15 ns on Linux. Measured: about +48 ns and +10 ns per request on a ~1.3 µs operation. The idle-Worker workload and every other limit stay at 1.02. The tradeoff buys correct finalization for parked workers on Windows ARM64, where the request previously never freed the object.

• Own native CI: Linux and macOS green. The PR test merge tree exactly matches the source head.
• Own Windows ARM64 preview: all 41 compatibility rows pass, including all 293 tests in the unchanged worker file; owner-exit stress 50/50 pass. All three native smoke targets pass. Publication was disabled and the publish job skipped.
• Linux portable proof: unchanged target 10/10; 22 surrounding file commands, 443 tests pass, 7 skip and 1 todo. The ASAN-only file is skipped, not claimed as exercised. Diagnostic PR ci: measure async GC cost on Linux (diagnostic, do not merge) #210 is closed unmerged and its branch removed.
• Full-diff Codex P2 review, actual cppbind generation and formatting pass. The original immediate-GC test is byte-identical, with no timeout widening or retries.

The timed workloads are frozen: 200,000 GC requests (elapsed time) and 500 worker allocation/request/park turns (process CPU). Before this head's measurements, the cost rule was calibrated using the observed no-op control noise: in one interleaved cohort, each candidate/S8 median paired ratio must be at most max(1.02, noop/S8 + 0.01). Ten rounds include all three executables. All 120 raw platform measurements were independently validated, with no outlier removal or reruns. Five hundred requests do not imply five hundred separate collections or wakeups.

Ratios are medians of round-paired ratios, not quotients of the displayed absolute medians. Linux passes both gates. macOS Worker CPU passes, but its GC-loop ratio is 1.0344164 against 1.02 (no-op/S8 0.9920787). This failure prevents readiness despite the functional CI passes.

Earlier failures remain recorded: the byte-loop helper's macOS GC-loop ratio was 1.4232066. The subsequent empty-helper candidate does not qualify as a functioning fix. The forced-inline-store candidate f08 had macOS loop/worker ratios 0.9972685/1.0265994 and Linux ratios 1.0301770/0.9783200, failing its original 1.02 contract. It was not rerun or retroactively qualified under the calibrated rule.

The surrounding fd-tracking fixture change is retained as a test-only deterministic repair. Before, the Linux surrounding run failed because readiness preceded opens or streams drained before inspection. Now all ten streams are rooted and paused after their first chunk before readiness; the original descriptor assertions and deadline remain. It passes in current Linux portable proof and both native CI lanes.

The next implementation would need to reduce the fixed-size clearing cost while preserving its range and both call sites, then qualify a genuinely changed head. Shrinking the range, dropping platform coverage, or gating clearing on pending collections would need separate evidence or a design decision. No performance exception is assumed here.

The remaining engine follow-up is to capture collection-time marking provenance and identify why the newer stack layout retains this value. Register/stack-capture source is unchanged between the compared engine pins; the later parked-state dump cannot establish the retaining frame. This PR changes neither WebKit nor collection semantics.