Startup snapshots (1/4): dependency pins and build wiring - #37259
Startup snapshots (1/4): dependency pins and build wiring#37259Jarred-Sumner wants to merge 1 commit into
Conversation
a13e77d to
13be5cd
Compare
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe pull request configures startup snapshots for mimalloc and WebKit, adds deterministic mapping hints, and reinitializes BoringSSL fork detection after snapshot restoration. ChangesStartup snapshot integration
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/build/deps/mimalloc.ts`:
- Line 15: Replace the temporary preview pins with landed immutable merge SHAs:
update MIMALLOC_COMMIT in scripts/build/deps/mimalloc.ts at line 15 and
WEBKIT_VERSION in scripts/build/deps/webkit.ts at line 6. Remove any references
to the unmerged preview artifacts while preserving the existing dependency
configuration.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 27e422ee-85f4-412d-94c7-7f32f19e3d56
📒 Files selected for processing (11)
patches/boringssl/fork-detect-startup-snapshot.patchscripts/build/deps/boringssl.tsscripts/build/deps/mimalloc.tsscripts/build/deps/webkit.tsscripts/build/flags.tssrc/boringssl_sys/boringssl.rssrc/boringssl_sys/lib.rssrc/bun_alloc/lib.rssrc/jsc/bindings/c-bindings.cppsrc/mimalloc_sys/mimalloc.rstest/js/node/process/process.test.js
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
15e79ea to
073c4ff
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/build/deps/webkit.ts`:
- Line 6: Do not merge the preview value in WEBKIT_VERSION; keep this change
blocked until WebKit PR `#397` lands, then replace it with the immutable merged
commit SHA and update the matching process.versions assertion together.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4afd1e05-dea3-423d-9099-4706ab508997
📒 Files selected for processing (1)
scripts/build/deps/webkit.ts
073c4ff to
0024501
Compare
8b1ebdf to
4c70ecd
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/build/deps/mimalloc.ts`:
- Around line 30-39: Parse BUN_MIMALLOC_OVERRIDE_DARWIN once in Config,
distinguishing unset, empty, and the accepted opt-in value "1" while rejecting
unsupported values; expose the resolved boolean through Config rather than
reading process.env here. Update both override and osxZone in this file and the
matching predicate in flags.ts to reuse that parsed value, keeping Darwin
override behavior synchronized.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: da464f09-6264-4713-a8aa-20ad63fb7078
📒 Files selected for processing (1)
scripts/build/deps/mimalloc.ts
4c70ecd to
341acdc
Compare
341acdc to
f0bc2af
Compare
There was a problem hiding this comment.
I re-reviewed after the latest push and found no issues — all three BUN_MIMALLOC_OVERRIDE_DARWIN sites (override, osxZone, and the BUN_MIMALLOC_ZONE_OVERRIDE define in flags.ts) now agree on === "1", resolving the last open thread. Given this is the foundation of a 4-PR feature stack, patches BoringSSL's RNG fork-detection, and is explicitly blocked on unmerged upstream pins, a human sign-off is still appropriate.
What was reviewed:
- The three Darwin-override predicates are now identical and gated on
!asan; the policy comment matches. bss_mmap_noreserve's hint path: constants named, hint is advisory (noMAP_FIXED), andfetch_addbump is monotonic.bun_is_compiled_executableon Windows returns 0 without touching the PE section (safe pre-main); the POSIX arm reads a static, no init-order concern.- The BoringSSL patch defines the reinit hook once per
#ifarm (WIPEONFORK / atfork / no-op ×2) — no duplicate-symbol risk.
Extended reasoning...
Overview
First of four stacked PRs for startup snapshots. Changes: mimalloc/WebKit pins to preview artifacts (explicitly not mergeable until upstream lands), a new BoringSSL patch adding CRYPTO_fork_detect_reinit_for_startup_snapshot, build-script wiring for the Darwin malloc-zone opt-in and mimalloc's snapshot-hint hook, an mmap address-hint path in bun_alloc, bun_is_compiled_executable in c-bindings.cpp, and matching FFI declarations in mimalloc_sys/boringssl_sys. Every new symbol is unused until PR 2.
Security risks
The BoringSSL patch touches RNG fork-detection state (g_fork_detect_addr, g_fork_generation, atfork registration). The patch itself only adds a re-init hook — it does not change existing CRYPTO_get_fork_generation behavior — and the hook is not yet called anywhere in this PR. The correctness of when it is called (single-threaded restore, before any RAND_bytes) is the security-load-bearing part, and that lives in PR 2. Nothing else here is security-sensitive.
Level of scrutiny
High. This is not a mechanical change: it patches a vendored crypto library, alters allocator address placement, adds cross-platform build defines with a documented invariant ("keep in step"), and pins two core dependencies to preview builds of unmerged PRs. It is also the base of a stacked feature, so design choices here (e.g., MI_STARTUP_SNAPSHOT_HOST_FN=bun_is_compiled_executable, the 0x1f0_0000_0000 reserve base, USE_EXTERNAL_MIMALLOC for WebKit) constrain the next three PRs.
Other factors
- The author has been responsive; every prior finding from this bot (magic-number naming,
!cfg.asangating, policy-comment drift, predicate divergence) is addressed in the current diff. - The PR description already states it is blocked on oven-sh/WebKit#397 and oven-sh/mimalloc#13; approving before those land would be premature regardless.
- No automated test exercises the new code paths (by design — nothing calls them yet); the only test change is the
process.versions.mimallochash bump. - The WebKit
USE_MIMALLOC/USE_EXTERNAL_MIMALLOCcmake flags and the mimallocMI_STARTUP_SNAPSHOT_*defines depend on the preview builds' internals, which I cannot verify from this repo alone.
f0bc2af to
40f093c
Compare
560aef8 to
aeb2481
Compare
225819e to
41cd003
Compare
c3715f8 to
70dad1a
Compare
There was a problem hiding this comment.
I reviewed this round and the bug-hunting pass found nothing new — all prior inline findings have been addressed (the bss_singleton! race was left as-is with a stated reason, which is fine). Given this is the foundation of a stacked feature, patches BoringSSL's fork-detection/RNG path, and is self-declared not-mergeable until the mimalloc/WebKit pins swap to merged SHAs, a human sign-off is still the right call.
What was reviewed:
- BoringSSL fork-detect reinit hook: never-initialized guard, WIPEONFORK-unavailable fallback, generation advance past the builder's value — all four
#ifvariants covered. bun_allochint machinery:map_arena_onceclaim-before-map serializes hint consumption;snapshot_reserve_hintcfg-gating matches the mimalloc build'ssnapshotspredicate.c-bindings.cpp:bun_is_compiled_executabledefined on every ELF/Mach-O + Windows stub; the placement predicate bounds-checks the trailer before reading offsets.- Build wiring:
osxZone/BUN_MIMALLOC_ZONE_OVERRIDEpredicates kept in step;USE_MIMALLOCexcluded under ASAN like every other mimalloc routing.
Extended reasoning...
Overview
First of four stacked PRs for startup snapshots. This one carries only dependency pins and build-time wiring: a BoringSSL patch adding a fork-detection re-init hook, mimalloc/WebKit commit bumps to preview builds with snapshot support, a new snapshot_reserve_hint in bun_alloc so the fixed reservation follows mimalloc's deterministic-hint mode, a pre-main predicate in c-bindings.cpp that mimalloc calls to decide whether to enable that mode, and the FFI declarations for the new symbols. Every new symbol is unused until #37260.
Security risks
The BoringSSL patch touches crypto/rand/fork_detect.cc, which drives DRBG reseeding across address-space duplication. Earlier rounds surfaced and fixed: a page-mapping leak / double-registration when the build process never initialized fork detection; an ambiguous null-address guard on pre-4.14 kernels (now documented as falling through to always-reseed, which is safe); and the generation being reset to 1 rather than advanced past the builder's value (now saved+1). The hook is a no-op on the two #else platforms. Nothing else in the diff is security-sensitive; the payload-trailer parser in c-bindings.cpp reads only this executable's own baked-in section and length-checks before the memcmp.
Level of scrutiny
High. This is allocator- and RNG-adjacent, runs before main, and the correctness of address determinism can only be fully validated once #37260 lands and exercises it. The author explicitly marks the PR not-mergeable until the two upstream fork PRs merge and the pins move off preview artifacts. That alone rules out auto-approval.
Other factors
The PR has been through ~10 review rounds already; every prior finding was either fixed or explicitly declined with a rationale (the bss_singleton! init-then-CAS race, which is documented single-threaded and not snapshot-address-load-bearing). No open reviewer requests remain. The process.versions.mimalloc test assertion was updated in step with the pin. Deferring rather than approving because the scope — patching BoringSSL's RNG machinery and repointing two core dependencies to unmerged preview builds — is exactly the kind of change a maintainer should see before it lands.
4fdfd3e to
4776d6a
Compare
There was a problem hiding this comment.
I reviewed this revision and found no new issues; the earlier inline findings (BoringSSL fork-detect reinit, bun_alloc hint-consumption race, c-bindings predicate scoping/comments) have all been addressed. Given this touches BoringSSL's RNG fork-detection path, allocator placement semantics, and dependency pins the description marks as not-yet-mergeable, a human look is still warranted before landing.
Reviewed: the fork-detect patch's four #if variants (early-return guards, saved+1 generation bump, no-op stubs); map_arena_once's claim-then-map ordering vs. snapshot_reserve_hint's fetch_add; bun_startup_snapshot_placement_wanted's trailer bounds checks and Darwin/ELF payload-address handling; the osxZone/BUN_MIMALLOC_ZONE_OVERRIDE predicate matching between flags.ts and mimalloc.ts; and the ASAN-gating consistency of the new USE_MIMALLOC/USE_EXTERNAL_MIMALLOC cmake args in webkit.ts.
Extended reasoning...
Overview
First of four stacked PRs wiring dependency-side support for startup snapshots. Touches: a new BoringSSL patch (fork-detect-startup-snapshot.patch) adding CRYPTO_fork_detect_reinit_for_startup_snapshot across all four #if branches of fork_detect.cc; build-script changes in scripts/build/deps/{boringssl,mimalloc,webkit}.ts and scripts/build/flags.ts (mimalloc/WebKit commit pins to preview artifacts, MI_STARTUP_SNAPSHOT_* defines, MI_OSX_ZONE opt-in via BUN_MIMALLOC_OVERRIDE_DARWIN, USE_MIMALLOC/USE_EXTERNAL_MIMALLOC for local WebKit builds, BUN_MIMALLOC_ZONE_OVERRIDE compile define); Rust FFI declarations in boringssl_sys and mimalloc_sys; bun_alloc/lib.rs — snapshot_reserve_hint and a rewrite of bss_arena_bump's cold path from map-then-CAS to claim-then-map; c-bindings.cpp — bun_is_compiled_executable and bun_startup_snapshot_placement_wanted (the mimalloc host predicate) plus a Windows stub; and a one-line mimalloc SHA update in process.test.js.
Security risks
The BoringSSL patch touches the RNG's fork-detection machinery. If the reinit hook left a restored process able to reuse the build process's DRBG state, every restored instance would produce identical RAND_bytes output. Over the review cycle this was hardened three times (early-return when never initialized in the builder, comment covering the WIPEONFORK-unavailable fallback, and generation_in_builder + 1 so any surviving cached generation is guaranteed to mismatch). The hook has no caller in this PR; the actual restore semantics land in #37260, so the residual risk is that #37260's capture/restore doesn't uphold the single-threaded / fresh-TLS assumptions the # Safety block and patch comments state — that belongs to the next PR's review. The trailer-parsing predicate in c-bindings.cpp reads a trusted, linker-embedded payload (not user input), bounds-checks total length before the trailer memcmp and offset reads, and uses memcpy into locals rather than aligned loads on the ELF path.
Level of scrutiny
High. This is not a mechanical change: it patches a vendored crypto library's fork-detection statics, changes allocator arena-mapping race semantics for determinism, introduces a pre-main hook the allocator calls, and repins two core dependencies to unmerged preview builds. The PR description itself says "Not mergeable as-is" pending oven-sh/mimalloc#13 and oven-sh/WebKit#397, and the correctness of several pieces (the Offsets layout constants, mi_startup_snapshot_hints_enabled, the restore caller) depends on code landing in those external PRs and in #37260. Per the approval guidelines — security-sensitive code, large-scale design decisions, and an explicitly not-yet-landable state — this should not be auto-approved.
Other factors
The review cycle here was extensive: six inline findings across prior runs, all resolved by the author (one — the bss_singleton! CAS-and-leak sibling — intentionally left as-is with a stated rationale that first touch is single-threaded and its address is not a snapshot dependency, which is reasonable). No new findings this run. There is essentially no new automated test coverage in this PR (only a version-string update), which is expected since every new symbol is unused until #37260; the combined branch (#37225) carries the cross-platform CI. A maintainer should confirm the kOffsetsSize/kOffsetsFlagsOffset/kOffsetsSnapshotLengthOffset/kTakeStartupSnapshotFlag constants against StandaloneModuleGraph.rs (the comment says a const-assert lands with the runtime PR), and sign off on the macOS zone-override opt-in and the WebKit USE_EXTERNAL_MIMALLOC routing before the pins are swapped to merged SHAs.
08417c1 to
5d932e6
Compare
5d932e6 to
8ef2219
Compare
There was a problem hiding this comment.
I reviewed this revision and found no new issues; all earlier inline findings have been addressed. Because this is the foundation of a feature stack, patches BoringSSL's RNG fork-detection, and rewrites allocator concurrency behavior — and is self-described as not mergeable until the mimalloc/WebKit pins are swapped — a human look is still warranted.
What was reviewed:
- BoringSSL fork-detect patch: never-initialized / WIPEONFORK-unavailable guards, generation-advance on restore, dead-store cleanup; all four
#ifvariants define the symbol. bun_alloc: claim-then-map serialization of the arena base so at most oneSNAPSHOT_HINTis consumed; hint cfg matches the mimalloc.tssnapshotsgate (macOS/Linux/Android only, FreeBSD stubbed).c-bindings.cpp: trailer-magic + length bounds before readingOffsets;memcpyavoids the 16K-aligned typed deref on 4K-page ELF;bun_is_compiled_executabledefined on every platform, placement predicate only where mimalloc asks for it.- Build wiring: Darwin override/zone and
BUN_MIMALLOC_ZONE_OVERRIDEall gate on!cfg.asanand the same=== "1"test; WebKitUSE_MIMALLOCexcludes ASAN like the sibling sites.
Extended reasoning...
Overview
First of four stacked PRs wiring startup-snapshot support into the dependency layer: bumps mimalloc/WebKit to preview builds carrying the snapshot machinery, adds a BoringSSL patch exposing CRYPTO_fork_detect_reinit_for_startup_snapshot, teaches bun_alloc's fixed reservation to follow mimalloc's deterministic-hint mode, adds a pre-main predicate (bun_startup_snapshot_placement_wanted) that mimalloc calls to decide whether to enable hints, and threads the corresponding build defines through mimalloc.ts/webkit.ts/flags.ts. Every new symbol is unused until #37260.
Security risks
The BoringSSL patch touches the RNG's fork-detection statics — the mechanism that forces DRBG reseeding after address-space duplication. Across review rounds this converged to: guard on prior-init state (covering both the never-ran and WIPEONFORK-unavailable cases), reset the stale page address so a failed re-init falls through to always-reseed, and advance the generation past the builder's value so any surviving cached state is forced to reseed. The Rust wrapper is unsafe fn with a # Safety block requiring single-threaded restore. The design looks sound and fails closed, but this is exactly the class of change (crypto RNG state across process-image duplication) that deserves a human sign-off.
Level of scrutiny
High. Beyond the crypto patch, the bun_alloc change replaces a well-understood map-then-CAS-and-leak race policy with a claim-then-spin-wait; bun_startup_snapshot_placement_wanted runs before main from inside the allocator and hand-decodes a trailer whose layout is const-asserted only by a later PR in the stack; and the mimalloc/WebKit pins are placeholder preview artifacts the author plans to swap. None of this is mechanical.
Other factors
This PR has been through ~20 inline-finding rounds with fix commits for each (ASAN gating, FreeBSD symbol placement, comment accuracy, alignment UB, unsafe fn on the reinit wrapper, hint-consumption determinism, generation-advance, dead-store removal). The author explicitly declined one nit (bss_singleton! claim-first) with a stated rationale, which is recorded in an unresolved thread. The PR description itself flags it as not mergeable until the dependency PRs land, so a human will need to re-check the final pins regardless. Given all of that, deferring rather than approving.
8ef2219 to
46ecdff
Compare
There was a problem hiding this comment.
I reviewed this revision and found no new issues. Given the scope — vendored crypto patches (BoringSSL fork-detect), allocator placement changes, and dependency pins that the description marks as not-yet-mergeable — a maintainer look is still warranted before this lands.
What was reviewed:
- BoringSSL fork-detect patch: generation-advance semantics, the null-addr guard's two states, and that the address reset is load-bearing while the dead
= 0store is gone. bun_allocclaim-then-map rewrite: exactly one hint consumed regardless of racing; thebss_singleton!sibling was intentionally left as-is per the author's reply.- Platform gating:
snapshot_reserve_hintcfg, theOS(DARWIN) || __linux__guard on the placement predicate, and the threeBUN_MIMALLOC_OVERRIDE_DARWINsites now agree (all=== "1"and!cfg.asan). bun_startup_snapshot_placement_wanted: bounds-checked trailer read via memcpy, no typed deref through the 16K-aligned BlobHeader on ELF.
Extended reasoning...
Overview
First of four stacked PRs wiring startup-snapshot support into the build. Touches: dependency pins (mimalloc, WebKit → preview artifacts of unmerged upstream PRs), a new BoringSSL patch adding CRYPTO_fork_detect_reinit_for_startup_snapshot, build defines in scripts/build/deps/{mimalloc,webkit,boringssl}.ts and flags.ts, allocator changes in src/bun_alloc/lib.rs (snapshot_reserve_hint, claim-then-map map_arena_once), two new C predicates in c-bindings.cpp, FFI declarations in mimalloc_sys/boringssl_sys, and a version-assertion bump in process.test.js. The PR description explicitly states it is not mergeable until the upstream mimalloc/WebKit PRs land and the pins swap to merged SHAs.
Security risks
The BoringSSL patch modifies crypto/rand/fork_detect.cc — the mechanism that forces DRBG reseeding after address-space duplication. A bug here could cause identical RNG output across restored processes. The patch has been through several correction rounds and now advances the fork generation past the builder's value (fail-closed), resets g_fork_detect_addr so a failed re-init falls back to always-reseed, and defines no-op stubs on the two platforms that don't use fork detection. The Rust wrapper is unsafe fn with a # Safety block naming the single-threaded precondition. This looks correct, but crypto RNG state management is exactly the kind of thing that warrants a maintainer's sign-off.
Level of scrutiny
High. This is foundational work for a new runtime capability (heap snapshots) that spans the allocator, JSC, and BoringSSL. It changes vendored crypto, rewrites an allocator init path, and pins two core dependencies to unmerged preview builds. None of it is a mechanical or config-only change.
Other factors
This revision is the first to come through with zero findings after roughly twenty rounds of inline feedback, all of which the author addressed (or explicitly declined with a reason, in the bss_singleton! case). The remaining new symbols are all unused until #37260, so behavior in a standalone build is unchanged except for the claim-then-map rewrite of bss_arena_bump (which is a strict correctness improvement over the prior leak-the-loser policy). The author has already flagged that the pins must be swapped before landing.
e85b904 to
feaefd2
Compare
There was a problem hiding this comment.
I reviewed this revision and found no new issues — the earlier findings (hint-consumption race in bss_arena_bump, fork-generation semantics, the dead g_fork_generation = 0 store, comment accuracy) have all been addressed. Given this is the foundation of a 4-PR feature stack that touches allocator placement, BoringSSL's RNG fork-detection, and bumps the WebKit/mimalloc pins (to preview builds the description marks as not-mergeable-as-is), a human sign-off is still warranted.
What was reviewed:
bun_alloc: the new claim-then-mapmap_arena_onceandsnapshot_reserve_hint— checked the spin-wait loser path and that only one hint is consumed per arena; thebss_singleton!sibling was intentionally left as-is per the author's reply.- BoringSSL patch: both WIPEONFORK and pthread_atfork variants now advance the generation past the builder's; the
g_fork_detect_addr = nullptrreset is kept (load-bearing for the < 4.14 restore-host fallback), and the two no-op-platform stubs cover all four#ifbranches. c-bindings.cpp:bun_startup_snapshot_placement_wantedbounds-checkslenagainstkOffsetsSize + trailerbefore the trailer memcmp and reads flags/snapshotLength viamemcpy(no alignment assumption on the ELF path);bun_is_compiled_executableis defined on every ELF/Mach-O build plus the Windows stub.- Build wiring: the
osxZone/BUN_MIMALLOC_ZONE_OVERRIDEpredicates match, and both are gated on!cfg.asanlike the other mimalloc-routing sites.
Extended reasoning...
Overview
First of four stacked PRs for startup snapshots. Changes: WebKit and mimalloc pins bumped to preview builds of unmerged upstream PRs; a new BoringSSL patch adding CRYPTO_fork_detect_reinit_for_startup_snapshot() (four #if-branch variants); build-script wiring for MI_STARTUP_SNAPSHOT_HOST_FN/MI_STARTUP_SNAPSHOT_BUILD_ENV, MI_OSX_ZONE, USE_MIMALLOC for local WebKit, and a BUN_MIMALLOC_ZONE_OVERRIDE define; bun_alloc's fixed reservation now follows the allocator's hint mode via a new snapshot_reserve_hint(), and the bss_arena_bump cold path was rewritten from map-then-CAS-and-leak to claim-then-map; two new pre-main C predicates in c-bindings.cpp; FFI declarations in boringssl_sys/mimalloc_sys; and the process.versions.mimalloc test assertion updated to the new commit.
Security risks
The BoringSSL patch touches the RNG's fork-detection state — the mechanism that forces DRBG reseeding after address-space duplication. An earlier revision reset the generation to 1 (same as the builder's cached value); that was fixed to saved + 1 so any surviving DRBG state would reseed. The remaining behavior on the < 4.14-Linux edge (WIPEONFORK unavailable in the builder) falls through to BoringSSL's always-reseed fallback, which is safe. The Rust wrapper's # Safety contract requires single-threaded restore, which the patch's comments and the next PR's design rely on. No injection/auth/data-exposure surface here — the risk class is "RNG state carried across a process boundary", and the current shape handles it correctly.
Level of scrutiny
High. This is not a mechanical change: it rewrites a concurrency primitive in the process-lifetime allocator, patches a vendored crypto library's RNG machinery, adds code that runs from inside mimalloc's own initialization before main, and repins the JS engine and the process allocator to unmerged preview artifacts. The PR description itself flags it as not mergeable as-is pending oven-sh/mimalloc#13 and oven-sh/WebKit#397 landing. Every new symbol is unused until #37260, so behavior is inert on its own — but the design decisions here (hint base at 0x1f0_0000_0000, the Offsets layout constants duplicated in C++, the macOS zone-override opt-in) are load-bearing for the whole stack.
Other factors
The PR has already been through many review rounds with substantive fixes applied (ASAN gating, FreeBSD #if scoping, the hint-consumption determinism race, fork-generation advancement, a dead store, and several comment-accuracy passes). The author responded to every finding and left one (bss_singleton!'s race policy) intentionally unchanged with a stated reason. No automated test in this PR exercises the new code paths — expected, since nothing calls them yet; coverage lands with #37260 and the combined branch #37225. The kOffsetsSize/kOffsetsFlagsOffset/kOffsetsSnapshotLengthOffset constants in c-bindings.cpp are duplicated from StandaloneModuleGraph.rs with a comment that the runtime PR const-asserts them — worth a human confirming that assertion actually lands in #37260.
feaefd2 to
2f0727e
Compare
There was a problem hiding this comment.
I reviewed this PR and found no new issues after the latest round of fixes. Given it patches BoringSSL's fork-detection/RNG path, rewires allocator placement, and is self-declared not-mergeable until oven-sh/mimalloc#13 and oven-sh/WebKit#397 land, a human sign-off is still warranted.
What was reviewed:
- BoringSSL
fork_detect.ccpatch: guard states, generation-advance semantics, dead stores, single-threaded contract — all four #ifdef variants define the symbol. bun_allochint machinery: claim-then-map serialization ofBASE,SNAPSHOT_HINTseeding/bump, cfg gating matches where mimalloc builds the hint hook.c-bindings.cpptrailer parse: bounds-checked before field reads, magic verified, ELF vaddr read via memcpy (not the 16K-aligned type); FreeBSD/Windows still getbun_is_compiled_executable.- Build wiring:
osxZone/override/USE_MIMALLOCall gate on!cfg.asanconsistently with sibling sites.
Extended reasoning...
Overview
First of four stacked PRs for startup snapshots. Adds a BoringSSL patch (CRYPTO_fork_detect_reinit_for_startup_snapshot) so a restored process re-runs fork-detection setup; wires mimalloc's snapshot-hint hook and the Darwin zone-override define through the build scripts; makes bun_alloc's fixed reservation follow mimalloc's hint mode (with map_arena_once claim-then-map serialization); adds bun_is_compiled_executable / bun_startup_snapshot_placement_wanted in c-bindings.cpp for the allocator to query before main; bumps mimalloc/WebKit pins to preview artifacts. Every new symbol is unused until #37260.
Security risks
The BoringSSL patch touches the RNG's fork-generation machinery — the mechanism that forces a DRBG reseed after address-space duplication. The patch has been iterated to (a) fail closed when WIPEONFORK setup was unavailable in the builder, (b) advance the generation past the builder's value so any surviving cached-generation state reseeds, and (c) provide no-op stubs on platforms where fork detection is a constant. The Rust wrapper is unsafe fn with a documented single-threaded precondition. This is exactly the kind of change that should get a second pair of eyes.
Level of scrutiny
High. Allocator placement code that runs before main, a crypto-library patch, and cross-repo pins to unmerged PRs are each individually reasons to want human review; together they define the memory layout and RNG-safety invariants for the whole snapshot feature. The PR description also explicitly flags it as not mergeable as-is until the dependency PRs land and the pins are swapped to merged SHAs.
Other factors
The PR has been through ~20 rounds of automated nit-level findings, all addressed (ASAN gating, cfg consistency across FreeBSD/Windows, alignment-safe reads, dead-store removal, race-free hint consumption, comment accuracy). The one intentionally-unchanged item (bss_singleton! still uses init-then-CAS) has a stated rationale from the author. No automated test can exercise the new hooks yet — they are dead until #37260 — so correctness rests on code reading and the combined-branch CI in #37225.
There was a problem hiding this comment.
I reviewed this PR and found no issues in the current revision. Given that it's explicitly marked "not mergeable as-is" (preview pins for unmerged mimalloc/WebKit PRs), touches BoringSSL fork-detection/RNG state and pre-main allocator placement, and is the base of a 4-PR stack, a human look is still warranted before landing.
What was reviewed:
- The fork-detect patch: both WIPEONFORK and pthread_atfork variants advance the generation past the builder's; the null-addr guard's two states are documented; no-op stubs cover the remaining
#ifbranches. bun_alloc:map_arena_oncenow claims-then-maps so exactly one hint is consumed;snapshot_reserve_hintis cfg-gated to match where mimalloc's hint machinery is built; the mmap hint stays advisory.c-bindings.cpp:bun_startup_snapshot_placement_wantedbounds-checkslenbefore the trailer memcmp and reads flags/snapshotLength viamemcpy; the ELF path avoids reading through the 16K-aligned type;bun_is_compiled_executableis defined on every ELF/Mach-O build plus a Windows stub.- Build wiring:
osxZone/BUN_MIMALLOC_ZONE_OVERRIDEand WebKit'sUSE_MIMALLOCall gate on!asan, consistent with existing mimalloc routing.
Extended reasoning...
Overview
First of four stacked PRs for startup snapshots. This one is dependency pins and build wiring only — no runtime behavior change yet. It bumps mimalloc and WebKit to preview builds, adds a BoringSSL patch introducing CRYPTO_fork_detect_reinit_for_startup_snapshot() (with a Rust wrapper), threads new MI_STARTUP_SNAPSHOT_* defines and BUN_MIMALLOC_ZONE_OVERRIDE through the build, adds snapshot_reserve_hint in bun_alloc so the fixed reservation follows mimalloc's hint mode, and adds bun_is_compiled_executable / bun_startup_snapshot_placement_wanted in c-bindings.cpp for the allocator's pre-main hook. Every new symbol is unused until #37260.
Security risks
The BoringSSL patch rewrites fork-detection statics that gate DRBG reseeding — a mistake here could cause identical RNG output across restored processes. The current shape looks correct: the hook advances the fork generation past the builder's value (so any surviving cached state reseeds), resets g_fork_detect_addr before re-init (so a failed re-init falls back to always-reseed), and the Rust wrapper is unsafe with a documented single-threaded contract. This is exactly the kind of change a human should sign off on.
Level of scrutiny
High. This touches vendored crypto, process-global allocator placement invariants (deterministic addresses across processes), and pre-main code paths. The PR description itself says it is not mergeable as-is because the pins reference unmerged upstream PRs. It is also the foundation of a 4-PR stack; the layout constants in c-bindings.cpp (kOffsetsSize, field offsets, flag bit) are asserted against StandaloneModuleGraph.rs only in #37260, so they should be reviewed together.
Other factors
The PR has already been through many rounds of iterative bot review (hint-consumption race, fork-generation semantics, dead stores, comment cleanups), all addressed by the author with fix commits. One nit — the bss_singleton! init-then-CAS policy — was intentionally left as-is with a stated rationale (first touch is single-threaded; the arena's address is what a snapshot depends on, not the singleton's). This run found nothing new. The combined branch (#37225) is where full-platform CI runs.
There was a problem hiding this comment.
I reviewed this PR and the current revision is clean — all prior inline findings have been addressed. Because it patches BoringSSL's fork-detection/RNG path, changes allocator placement semantics, and (per the description) still pins preview artifacts that need swapping before landing, a human look is still warranted.
What was reviewed:
- BoringSSL fork-detect reinit hook: generation now advances past the builder's value; the null-addr guard's two states (never-init vs. WIPEONFORK-unavailable) both fall through safely; dead
g_fork_generation = 0store removed. bun_alloc:map_arena_onceclaim-then-map serializes hint consumption soBASEis deterministic;snapshot_reserve_hintcfg-gated to matchdeps/mimalloc.ts'ssnapshotspredicate.c-bindings.cpp:bun_startup_snapshot_placement_wantedbounds-checks the trailer before readingOffsets;bun_is_compiled_executabledefined on every ELF/Mach-O build (FreeBSD included) plus a Windows stub.- Build wiring:
BUN_MIMALLOC_ZONE_OVERRIDE/osxZone/USE_MIMALLOCall consistently gated on!asan.
Extended reasoning...
Overview
First of four stacked PRs for startup snapshots. Touches dependency build scripts (mimalloc, WebKit, BoringSSL), adds a BoringSSL patch exposing CRYPTO_fork_detect_reinit_for_startup_snapshot, adds Rust FFI declarations for it and for mi_startup_snapshot_hints_enabled, reworks bun_alloc's lazy-BSS arena to follow mimalloc's deterministic-hint mode, and adds two C++ predicates in c-bindings.cpp that mimalloc/StartupSnapshot.cpp will call. Every new symbol is unused until #37260; the PR description states it is not mergeable as-is because the mimalloc and WebKit pins point at preview artifacts of unmerged upstream PRs.
Security risks
The BoringSSL patch touches fork-detection state that gates DRBG reseeding — a wrong reinit could leave a restored process reusing the builder's RNG state. This was examined in depth across earlier review rounds: the hook now (a) early-returns when fork detection never ran or fell back to always-reseed, (b) nulls g_fork_detect_addr before re-init so a failed re-init on the restore host stays in the always-reseed fallback rather than dereferencing the builder's unmapped page, and (c) advances the generation past the builder's cached value so any surviving DRBG state would reseed. The Rust wrapper is unsafe with a documented single-threaded contract. No other security-sensitive surface is touched.
Level of scrutiny
High. This is foundational work for a large feature, patches a vendored crypto library, changes process-wide allocator address-placement behavior, and rewrites a lock-free init path in bun_alloc. It has already been through ~20 review rounds on this thread (Windows-stub placement, FreeBSD cfg gating, ASAN gating consistency, hint-consumption determinism, fork-generation semantics, dead-store cleanup), all of which the author addressed. The one intentionally-unaddressed nit (bss_singleton!'s CAS-and-leak policy) has a stated rationale from the author and does not affect snapshot correctness.
Other factors
- The author explicitly flags the preview pins as blockers; a maintainer needs to confirm the upstream mimalloc/WebKit PRs have merged and the pins swapped.
- No behavior changes on their own (new symbols unused until #37260), so test coverage is limited to the
process.versions.mimallocassertion; the combined branch (#37225) carries the end-to-end tests. - Allocator/crypto/build-system changes of this shape are outside the "simple, mechanical, or obvious" bar for auto-approval.
There was a problem hiding this comment.
I reviewed this PR and didn't find any bugs. Because it's the foundation of a 4-PR stack that patches BoringSSL's fork-detection (RNG reseed), rewires allocator placement, and pins WebKit/mimalloc to preview artifacts the description marks as not-yet-final, a human sign-off is still warranted.
Checked: all four #if arms of fork_detect.cc define the reinit symbol exactly once, and both functional variants advance the generation past the builder's value.
Checked: map_arena_once claims before mapping so exactly one placement hint is consumed; the snapshot_reserve_hint cfg set matches the snapshots predicate in deps/mimalloc.ts.
Checked: bun_startup_snapshot_placement_wanted bounds-checks len against trailer+offsets before the memcmp and field reads; FreeBSD keeps bun_is_compiled_executable but not the placement hook, matching where mimalloc is given MI_STARTUP_SNAPSHOT_HOST_FN.
Checked: the osxZone / BUN_MIMALLOC_ZONE_OVERRIDE predicates in deps/mimalloc.ts and flags.ts agree (darwin ∧ ¬asan ∧ env opt-in).
Extended reasoning...
Overview
First of four stacked PRs wiring dependency-side support for startup snapshots. Touches: a new BoringSSL patch adding CRYPTO_fork_detect_reinit_for_startup_snapshot() across all four fork_detect.cc compile arms plus its Rust FFI declaration and safe wrapper; mimalloc/WebKit commit pins bumped to preview artifacts of unmerged upstream PRs; new mimalloc build defines (MI_STARTUP_SNAPSHOT_BUILD_ENV, MI_STARTUP_SNAPSHOT_HOST_FN, opt-in Darwin zone override) and a matching BUN_MIMALLOC_ZONE_OVERRIDE C++ define; bun_alloc's fixed reservation now asks mimalloc for a deterministic placement hint and its arena-mapping cold path was rewritten from map-then-CAS to claim-then-map; two new C entry points in c-bindings.cpp (bun_is_compiled_executable, bun_startup_snapshot_placement_wanted) that read the standalone-graph payload trailer before main; a mi_startup_snapshot_hints_enabled FFI declaration; and the process.versions.mimalloc test hash bump.
Security risks
The BoringSSL patch sits directly on the RNG's fork-detection path: getting the reinit wrong could leave a restored process reusing the builder's DRBG state or dereferencing an unmapped MADV_WIPEONFORK page. The patch has been through several rounds here (never-initialized guard, state-(b) fallback comment, generation-advance to builder+1, dead-store removal) and the current shape looks correct against upstream fork_detect.cc — but crypto-adjacent vendored patches are exactly the class REVIEW.md flags for human review. The c-bindings.cpp payload-trailer reader runs before main from inside the allocator; it bounds-checks length before the trailer memcmp and uses memcpy for the unaligned field reads, so no obvious pre-main UB, but it hard-codes Offsets layout constants whose ground truth lives in a later PR.
Level of scrutiny
High. This is foundational infrastructure for a major runtime feature, the description explicitly says "Not mergeable as-is" (preview pins must be swapped for merge SHAs once oven-sh/mimalloc#13 and oven-sh/WebKit#397 land), and it touches allocator internals plus a security-sensitive vendored crypto patch. None of that fits the "simple, mechanical, obvious" bar for auto-approval.
Other factors
Prior automated review rounds raised 22 inline findings; all were addressed by the author except one nit on bss_singleton! that was explicitly declined with a stated rationale (its address is not something a snapshot depends on directly, unlike the arena's). This run found nothing new. The one remaining unresolved thread is that declined nit, which does not block. No automated tests are added for the new code paths, which is expected — every new symbol is unused until #37260, and the description points at #37225's combined CI for cross-platform coverage.
There was a problem hiding this comment.
I reviewed the latest revision and found no new issues after the dead-store removal. Since this is the foundation of a 4-PR feature stack, touches BoringSSL's RNG fork-detection and allocator placement, and (per the description) pins two unmerged upstream PRs that must land first, a human look is still warranted before this merges.
What was reviewed:
- BoringSSL fork-detect reinit hook — generation advances past the builder's value; the null-addr guard's two states (never-initialized vs WIPEONFORK-unavailable) both fall through safely; no-op stubs cover the remaining
#elsebranches. bun_allocclaim-then-map arena init andsnapshot_reserve_hint— one hint consumed regardless of racers; the cfg split matches wheremi_startup_snapshot_hints_enabledexists.bun_startup_snapshot_placement_wanted— length + trailer-magic checked before reading the offsets; ELF header read via memcpy to avoid the 16K-aligned-type deref.- Build wiring —
!cfg.asanon every new mimalloc-routing site; the host-fn hook andBUN_MIMALLOC_ZONE_OVERRIDEdefine stay in step across mimalloc.ts / flags.ts.
Extended reasoning...
Overview
This PR is part 1 of a 4-PR stack introducing startup snapshots. It touches build scripts (scripts/build/deps/{mimalloc,webkit,boringssl}.ts, flags.ts), a new BoringSSL patch adding CRYPTO_fork_detect_reinit_for_startup_snapshot, Rust FFI declarations in boringssl_sys/mimalloc_sys, allocator changes in bun_alloc/lib.rs (deterministic mmap hints + claim-then-map arena init), and two new C functions in c-bindings.cpp that read the compiled-executable payload trailer before main. The PR description explicitly marks it not mergeable as-is because the mimalloc/WebKit pins point at preview artifacts of unmerged upstream PRs.
Security risks
The BoringSSL patch rewrites fork-detection statics that gate DRBG reseeding. Over ~22 review rounds the hook was hardened to (a) leave the always-reseed fallback intact when WIPEONFORK was unavailable in the builder, (b) advance the generation past the builder's cached value so any surviving DRBG state would reseed, and (c) reset g_fork_detect_addr before re-init so a failed re-init falls closed. The Rust wrapper is pub unsafe fn with a # Safety contract requiring single-threaded restore. I don't see remaining RNG-safety gaps in this PR's surface, but this is exactly the kind of security-sensitive vendored-crypto change a maintainer should sign off on. The payload-trailer parser in c-bindings.cpp runs before main on data baked into the executable itself (not attacker-controlled at that point), and bounds-checks length + magic before reading the offsets.
Level of scrutiny
High. This is not a mechanical change: it establishes cross-process address-determinism invariants the rest of the stack depends on, patches a vendored crypto library's RNG-safety machinery, adds pre-main code called from inside the allocator, and bumps two forked dependencies to unmerged preview builds. The repo's own guidance flags dependency bumps and Node/Web-compat/allocator paths for extra care. The one open inline thread (bss_singleton! still using init-then-CAS) was explicitly declined by the author with a stated rationale, which is fine — but that's a maintainer call.
Other factors
The PR has iterated through many correction rounds (magic constants named, ASAN gating added everywhere, FreeBSD/Windows symbol placement fixed, alignment UB in the ELF header read fixed via memcpy, the arena race made claim-first, the fork-generation semantics tightened, dead stores removed). All prior automated findings are resolved or explicitly acknowledged. No new findings surfaced on this pass. The only test change is a mimalloc SHA in process.versions, which will need updating again once oven-sh/mimalloc#13 merges. Given the author's own "not mergeable as-is" note and the scope, deferring rather than approving.
There was a problem hiding this comment.
Automated review is now clean — no findings this round after the earlier threads were addressed. Given this is the foundation of a stacked feature touching BoringSSL fork detection, allocator placement, and pre-main payload parsing (and is self-marked not-mergeable pending the mimalloc/WebKit merge SHAs), a human pass is still warranted.
What was reviewed:
- BoringSSL fork-detect patch: null-addr guard states,
saved+1generation advance, dead-store removal, all four#ifvariants present bun_allocclaim-then-map serialization andsnapshot_reserve_hintdeterminism under concurrent first-touchbun_startup_snapshot_placement_wantedtrailer length/magic checks and platform gating vs.bun_is_compiled_executable- Build-flag consistency across
deps/mimalloc.ts(snapshots/osxZone),flags.ts(BUN_MIMALLOC_ZONE_OVERRIDE), and the c-bindings#ifguards
Extended reasoning...
Overview
First of four stacked PRs wiring dependencies and build flags for startup snapshots. It bumps the mimalloc and WebKit pins to preview artifacts, adds a BoringSSL patch introducing CRYPTO_fork_detect_reinit_for_startup_snapshot() (with a Rust FFI wrapper), routes bun_alloc's fixed MAP_NORESERVE reservation through a new deterministic-hint helper backed by mi_startup_snapshot_hints_enabled(), adds bun_is_compiled_executable / bun_startup_snapshot_placement_wanted in c-bindings.cpp for the allocator's pre-main hook, threads MI_STARTUP_SNAPSHOT_* and MI_OSX_ZONE defines through the mimalloc build, adds a BUN_MIMALLOC_ZONE_OVERRIDE compile define, and updates the process.versions.mimalloc assertion. Every new symbol is unused until the next PR in the stack.
Security risks
The BoringSSL patch touches fork detection, which gates DRBG reseeding — a real crypto-RNG safety mechanism. The concerns examined over prior rounds (leaking the build process's WIPEONFORK page, the < 4.14 fallback state, generation not advancing past the builder's cached value, dead intermediate stores) have all been addressed in the current diff, and the hook is a no-op on the two #else branches. The Rust wrapper is unsafe fn with a documented single-threaded contract. No other security-sensitive surface (auth, TLS handshake, input parsing from untrusted sources) is touched; the payload-trailer read in bun_startup_snapshot_placement_wanted is bounds-checked against kOffsetsSize + sizeof kPayloadTrailer and magic-verified before field reads.
Level of scrutiny
High. This is foundational infrastructure for a major feature, spans four languages/build layers, patches a vendored crypto library, and rewrites a lock-free init path in the process allocator. It has already been through ~15 rounds of iterative review (all resolved or explicitly declined with reasoning — the one open thread on bss_singleton! was intentionally left as-is by the author). None of that changes the fact that the design choices here (hint base address, what the mimalloc hook is allowed to do before main, the macOS zone-override opt-in) deserve a maintainer's sign-off rather than bot approval.
Other factors
The PR description explicitly says not mergeable as-is — the WebKit and mimalloc pins point at preview artifacts of unmerged upstream PRs and must be swapped for merge SHAs (along with the process.versions test) before landing. That alone rules out auto-approval. The combined-branch CI run is on #37225; this PR's own test change is a one-line hash bump. Approving without a human confirming the upstream PRs merged and pins updated would be premature.
…loc's snapshot hint hook and the Darwin zone-override define; bun_alloc's fixed reservation follows the allocator's hint mode; BoringSSL fork-detection re-init hook
There was a problem hiding this comment.
I reviewed this revision and the bug-hunting pass found nothing new — every prior thread has been addressed or explicitly declined with a stated reason. Given that this patches BoringSSL's RNG fork-detection, rewires allocator placement (mimalloc/bun_alloc pre-main hooks), and is self-flagged as not mergeable until the upstream mimalloc/WebKit PRs land and the pins swap to merged SHAs, a human sign-off is still warranted.
What was reviewed:
- The fork-detect patch's four
#ifdefvariants: null-addr guard covers both "never ran" and "WIPEONFORK unavailable → always-reseed", generation is bumped past the builder's, and the address reset keeps the mmap-failure path failing closed. bun_alloc's claim-then-map serialization so exactly oneSNAPSHOT_HINTslot is consumed; thebss_singleton!sibling was raised and declined with reasoning.bun_startup_snapshot_placement_wanted's trailer parsing: length/magic checks precede the offset reads; ELF path avoids the 16K-aligned type on a 4K-aligned page via memcpy.- Build wiring:
osxZone/BUN_MIMALLOC_ZONE_OVERRIDEandUSE_MIMALLOCall gate on!asanconsistently; the mimalloc commit bump matches theprocess.versionsassertion.
Extended reasoning...
Overview
First of four stacked PRs laying dependency and build groundwork for startup snapshots. It bumps mimalloc and WebKit to preview builds carrying snapshot support, adds a BoringSSL patch exposing CRYPTO_fork_detect_reinit_for_startup_snapshot() (with a Rust FFI declaration and safe wrapper), threads new mimalloc build defines (MI_STARTUP_SNAPSHOT_HOST_FN, MI_STARTUP_SNAPSHOT_BUILD_ENV, MI_OSX_ZONE) and a matching BUN_MIMALLOC_ZONE_OVERRIDE define through flags.ts, adds snapshot_reserve_hint() to bun_alloc so its fixed reservation follows mimalloc's deterministic-placement mode, adds two pre-main predicates in c-bindings.cpp for the allocator and StartupSnapshot.cpp to query, and updates the process.versions.mimalloc test assertion.
Security risks
The BoringSSL patch sits directly on the CSPRNG fork-detection path. The concerns I traced across earlier rounds — stale WIPEONFORK page from the build process, generation not advancing past the builder's cached value, the < 4.14 madvise-failure state — have all been addressed and now fail closed (null address → generation-0 always-reseed; successful re-init → saved+1). The hook is uncalled in this PR; its # Safety contract requires single-threaded restore, which #37260 owns. bun_startup_snapshot_placement_wanted reads self-executable bytes with a magic-trailer + length guard before dereferencing offsets, so a malformed payload returns 0 rather than reading out of bounds.
Level of scrutiny
High. This is foundational plumbing for a major feature, touching the process allocator's initialization order, a vendored crypto library's RNG state machine, and two large dependency pins. It has already been through ~13 review rounds; the diff is now in a state where the automated pass surfaces nothing, but the combination of crypto + allocator + "runs before main" + preview-artifact pins is exactly the kind of change that should carry a human approval.
Other factors
The author explicitly marks the PR not mergeable as-is pending oven-sh/mimalloc#13 and oven-sh/WebKit#397; the pins and the process.versions test will need one more mechanical swap. One prior nit (the bss_singleton! race policy) was intentionally left as-is with a stated rationale — that thread is still open but not blocking. Every added symbol is unused until #37260, so behavioral coverage is deferred to that PR by design; the combined branch (#37225) carries the full-platform CI.
1 participant
First of four stacked PRs for startup snapshots: #37259 (deps) → #37260 (runtime +
Bun.startupSnapshot) → #37261 (bun build --snapshot) → #37262 (tooling). #37225 is the same content as one branch, kept open for the combined CI run until the stack is in.Not mergeable as-is: the two pins below point at preview artifacts of unmerged PRs. Once oven-sh/mimalloc#13 and oven-sh/WebKit#397 merge, this swaps to their merged SHAs (and the
process.versions.mimallocassertion with it).StackBounds' cached environ)scripts/build/flags.ts:BUN_MIMALLOC_ZONE_OVERRIDEdefine (macOS, only when mimalloc is the process allocator)bun_alloc: the fixed reservation follows the allocator's hint modepatches/boringssl/fork-detect-startup-snapshot.patch+boringssl_sysdeclarationMADV_WIPEONFORKpage → crash in the firstRAND_bytes); the hook re-runs its per-process setup. Called from the next PR.test/js/node/process/process.test.jsNothing here changes behavior on its own; every new symbol is unused until the runtime PR. Builds and passes standalone on macOS; the combined branch's CI (#37225) covers all platforms.