wasmtime / PR #14690 runtime: eliminate the shared global... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #14690 runtime: eliminate the shared global...

Wasmtime GitHub notifications bot (Oct 12 2026 at 23:10):

cfallin opened PR #14690 from cfallin:no-global-code-registry to bytecodealliance:main:

In some high-performance embeddings of Wasmtime, the embedder may try to avoid all inter-thread synchronization for deterministic-latency reasons, and may use an Engine per thread. Such embedders may also avoid using signal handlers altogether.

In a no-signals-based-traps, no-std build, Wasmtime shouldn't need the global code registry. This registry exists only to allow signal handlers for signals raised by the effects of trapping Wasm actions to find the appropriate module and trap code and take the appropriate action. When running without signals-based traps, the trap is instead implemented as a libcall, with the full Store accessible via an ordinary parameter passed to that libcall.

Hence, we should be able to remove usage of the registry.

This PR does so. There are some slight complications related to Pulley: Pulley always uses "signal"-based traps, where the signal is instead a software implementation of trapping behavior directly in the interpreter loop. For Pulley's case, this PR also adds a raw Store pointer to the CallThreadState. If that's not palatable, then I'm happy to figure out either how to exclude Pulley altogether from this "registry exemption", or refactor ownership/pointer linkages some other way.

This PR also carries some changes to the min-platform example, using it as an integration-test for this functionality. We now do an additional kind of smoke-test with separate pthreads (spawned from the host side) that invoke a "load and instantiate this module a bunch of times" entry point in the no-std Wasmtime library payload, with this build using the no-contention-only locking stubs, ensuring that we would have discovered locking contention if any locking/shared registry access actually occurred.

The min-platform example also needed some updating. Apparently it was silently failing module loads because, without virtual memory support, it could not make pages executable; it now does so with a custom code publisher. There was also a typo in an env var set from CI.

Wasmtime GitHub notifications bot (Oct 12 2026 at 23:10):

cfallin requested wasmtime-core-reviewers for a review on PR #14690.

Wasmtime GitHub notifications bot (Oct 12 2026 at 23:10):

cfallin requested fitzgen for a review on PR #14690.

Wasmtime GitHub notifications bot (Oct 12 2026 at 23:10):

cfallin requested wasmtime-default-reviewers for a review on PR #14690.

Wasmtime GitHub notifications bot (Oct 12 2026 at 23:10):

cfallin requested dicej for a review on PR #14690.

Wasmtime GitHub notifications bot (Oct 12 2026 at 23:45):

:memo: alexcrichton submitted PR review:

Sounds reasonable to me! One minor coment in registry.rs -- perhaps a #[cfg(...)] mod global; to avoid too much #[cfg] within the file itself?

For a broader comment about Pulley, I'd ideally like to keep the Pulley-related bits in interpreter-style modules as opposed to handling it too differently throughout the runtime. Reading over things again though I think it might be possible to avoid the use of test_if_trap entirely here on Pulley. The InterpreterRef::trap method is only called from InterpreterRef::call and that's already got a caller argument which should be a valid VMContext through which the store can be loaded (e.g. Instance::enter_host_from_wasm) and from there I think what you've got in this PR would suffice (look at the store's modules().store_code_by_pc(..) and such). That'd have a nice benefit where Pulley's behavior would be independent of #[cfg] and Pulley wouldn't actually need the global handler at all either.