Skip to content

Bump WebKit (oven-sh/WebKit#526 preview): honor a deferred GC request at the next VM entry - #40679

Draft
dylan-conway wants to merge 5 commits into
mainfrom
claude/webkit-deferred-gc-vm-entry
Draft

dylan-conway wants to merge 5 commits into
mainfrom
claude/webkit-deferred-gc-vm-entry

Conversation

@dylan-conway

Copy link
Copy Markdown
Member

What

Points WEBKIT_VERSION at the preview build of oven-sh/WebKit#526 (autobuild-preview-pr-526-6473271a) so the full test matrix runs against it — in particular test/cli/run/require-cache.test.ts on Windows x64, which has failed on main since the 8c4fd56347 WebKit upgrade (#40276).

Stacked on #40674 because the preview is built on oven-sh/WebKit main, which already contains the module-loader changes that PR adapts to. The only change on top of #40674 is the version string. Draft: for CI validation of the WebKit change; the real bump lands once oven-sh/WebKit#526 is merged.

Why

require-cache.test.ts › via require() with a lot of function calls re-requires a 100 KB module 500 times, does Bun.gc(true), and reads RSS. What it trips over is not a leak: JSC leaves a GC request pending (m_didDeferGCWork) when it is raised under DeferGCForAWhile — which is where the ~4 MB/iteration of CodeBlock metadata and baseline JIT code is reported — and nothing on this path picks it up for 30–90 iterations, so 100–280 MB of dead CodeBlocks pile into MarkedBlocks that are never swept again until the final synchronous GC, whose freed pages libpas returns ~100–250 ms after the test has read RSS. The WebKit PR honors the pending request at the next VM entry; details and measurements (perf/RSS/CPU across 17 workloads, GC counts unchanged) are in oven-sh/WebKit#526.

Jarred-Sumner and others added 5 commits August 27, 2026 23:44
…ises

With WebKit 86e19b8edd7c, ModuleRegistryEntry::provideModule() records the
source and module record without creating the fetch/module/load promises, and
markLoaded() tells the loader the record's [[LoadedModules]] is complete; the
loader materializes a settled promise only if some later load asks for one.
Use those instead of building a resolved load promise per module.

For a ~600-chunk compiled app this removes ~1,900 JSPromise allocations from
startup (2,986 -> 1,118 during --help); behaviour and host-hook counts are
unchanged.
… module evaluation without a promise per import edge
…ettling a load promise

No-Verification-Needed: comment-only change.
@robobun

robobun commented Aug 28, 2026 •

Copy link
Copy Markdown
Collaborator
Updated 6:44 PM PT - Aug 27th, 2026

❌ @dylan-conway, your commit de03a01 has 2 failures in Build #107160 (All Failures):


🧪   To try this PR locally:

bunx bun-pr 40679

That installs a local version of the PR into your bun-40679 executable, so you can run:

bun-40679 --bun

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants