Jarred Sumner's Bun is testing shared-memory threads inside JavaScriptCore

Why it matters

Shared-memory threads would move Bun's concurrency story from worker ergonomics into VM architecture, but the current evidence is still an open PR with unresolved safety and benchmark work.

Jarred Sumner (@jarredsumner) has opened a GitHub pull request in Bun's patched WebKit fork that proposes shared-memory threads for JavaScriptCore, the kind of runtime-level change that would let JavaScript code run a closure on another core while sharing the same heap.

The pull request, posted June 6, 2026 and still open as of June 20, is not a Bun release, not an upstream WebKit merge, and not a JavaScript standard proposal. The title itself says "experimental, not working yet." Sumner's own text is more precise: he says parallel JavaScript is executing through JavaScriptCore's four JIT tiers without a global lock, but also says thread-sanitizer cleanup, fuzzing, a benchmark regression, and a long soak remain before the work should be treated as anything beyond code for review. His caution is the right frame for the story: "It may never merge."

That caveat matters because the idea is large. The proposed API starts with new Thread(fn), where fn runs on another thread in the same heap and sees the variables, imports, classes, prototypes, and objects it closes over. Sumner's examples show join(), asyncJoin(), Thread.current, thread IDs, a Lock primitive, and use of Atomics on ordinary object properties.

For Bun, this is not a one-off feature sketch. It fits the pattern of Sumner pushing below the JavaScript toolchain surface and into the VM substrate Bun depends on. RuntimeWire reported in May that Sumner had merged Bun's Rust rewrite into main, framing that work around binary size, benchmarks, and compiler-assisted memory safety. This pull request sits one layer lower: not a package-manager improvement or test-runner polish, but an attempt to alter what JavaScriptCore can safely do with object graphs across CPU cores.

The bet is on object sharing, not worker ergonomics

JavaScript already has workers. Sumner's argument is that workers solve parallelism by drawing a boundary: separate heaps, postMessage, structured clone, transferable objects, and SharedArrayBuffer for code willing to model shared state as bytes. That can work for isolation. It is awkward for code whose real working set is a pile of JavaScript objects.

The PR's proposed model removes the boundary. A function passed to new Thread(heavy, input).join() remains a real closure rather than source text shoved into a blob-backed worker. A shared cache is an actual Map, not a cache-server worker. A cancellation flag is a property on an object. A progress counter is read directly. A parallel map can write into the same result array without chunking input and stitching together worker responses.

That is why this is a founder-level bet rather than just another Bun feature. Sumner is not merely smoothing the syntax around workers. He is betting that Bun can make JavaScript feel closer to the thread model of Java, Go, or C# while preserving VM safety: races in user code may produce stale or surprising values, but should not corrupt the JavaScript heap.

The PR says spawned threads would run in the same realm, with one globalThis, one set of built-ins, one prototype graph, and one already-executed module graph. That point is operationally important. A worker-heavy architecture often pays startup and duplication costs per worker: imports are loaded again, module-level side effects can rerun, and singleton assumptions break. Sumner's branch is designed around the opposite premise: if code is already in the heap, another thread can use it as code and data, subject to synchronization.

A 2017 WebKit idea, turned into a Bun-shaped implementation

Sumner's PR points back to Filip Pizlo's 2017 WebKit essay, "Concurrent JavaScript: It can work!", which laid out a strawman for threads in JavaScriptCore. That post described threads with separate stacks sharing everything else, plus changes to Atomics, lock and condition APIs, thread-local variables, and a way to restrict objects to a thread.

The new Bun-side branch reads like an implementation attempt of that long-dormant direction, adapted to the needs of a server-side JavaScript runtime. The PR says the work is behind --useJSThreads, so the engine is unchanged when the flag is off. It also says the locked fallback mode and threads-disabled configuration remain verified.

The design details are not cosmetic. The PR discusses engine-level semantics around promises, microtasks, and object sharing, with the aim that ordinary code can reason about a shared heap without breaking VM invariants.

The evidence is a public PR, not a release

The public evidence is an open pull request in oven-sh/WebKit, a fork of WebKit with patches, not an independent benchmark suite. The PR notes that one benchmark remains over budget and that additional parallel benchmarks are needed to validate scalability. Treat any performance or memory claims as provisional until third-party results exist.

The repository context shows why the work is visible even in unfinished form. Bun's main repository had about 93,300 stars when checked June 20, while oven-sh lists Bun as a JavaScript runtime, bundler, transpiler, and package manager. Bun's patched WebKit fork is much smaller as a public attention surface, but it is strategically central: it is where changes to JavaScriptCore can be staged before they become runtime behavior.

The hard part is not syntax

The clean API is the easy sell. The hard part is whether a production JavaScript runtime can expose shared objects without turning every library into a race condition generator.

Sumner's PR does not pretend that problem goes away. It adds a Lock API for synchronization. And because a shared object model still needs explicit atomic operations, the examples use Atomics on ordinary properties. The design is powerful precisely because it stops pretending concurrency can be made free.

That makes the open questions sharper. The PR does not establish whether this will ship in Bun, whether oven-sh will try to take it upstream to WebKit, or whether the broader JavaScript ecosystem would accept the semantics. It also does not publish the parallel benchmark results needed to show whether the shared-heap model delivers the payoff promised by the complexity.

Still, the pull request is a useful marker for where Sumner is trying to take Bun. The competitive story around JavaScript runtimes is often told through speed claims, compatibility tables, and package-manager ergonomics. This work is a deeper claim: Bun should not just run today's JavaScript faster; it should make a class of parallel JavaScript programs practical without forcing developers to rebuild their object graphs as messages or byte buffers.

If Sumner can get that right, Bun gets a feature that is difficult to copy at the API layer because the real work lives in the engine. If he cannot, the PR will still have served its stated purpose: putting a concrete implementation in front of the people capable of arguing with it.