Changes in registry.rs

6e0ded7c - Use `TryBTreeMap` in the store's `ModuleRegistry` (#12846)

Thu, 26 Mar 2026 16:46:22 +0000

Use `TryBTreeMap` in the store's `ModuleRegistry` (#12846) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

b90b8965 - Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)

Wed, 25 Feb 2026 00:01:48 +0000

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)We currently do a store-wide state-change on all registered moduleswhen the "single stepping" flag changes, patching in or out allbreakpoints. However, this design didn't account for modulesregistered with the store *after* single-stepping is enabled (and newmodules may be registered any time an instantiation occurs). Inparticular this is problematic when a debugger, e.g., sets thesingle-step flag right at the beginning of execution of a "host mainfunction" that calls Wasm, before the main instantiation occurs.This PR threads through the breakpoint state in the registration path,with the narrow waist at `ModuleRegistry::register` which is the onlyplace where modules are added to the `LoadedCode`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

17fbd3c6 - Debug: implement breakpoints and single-stepping. (#12133)

Fri, 12 Dec 2025 20:02:54 +0000

Debug: implement breakpoints and single-stepping. (#12133)* Debug: implement breakpoints and single-stepping.This is a PR that puts together a bunch of earlier pieces (patchablecalls in #12061 and #12101, private copies of code in #12051, and allthe prior debug event and instrumentation infrastructure) to implementbreakpoints in the guest debugger.These are implemented in the way we have planned in #11964: eachsequence point (location prior to a Wasm opcode) is now a patchable callinstruction, patched out (replaced with NOPs) by default. When patchedin, the breakpoint callsite calls a trampoline with the `patchable` ABIwhich then invokes the `breakpoint` hostcall. That hostcall emits thedebug event and nothing else.A few of the interesting bits in this PR include:- Implementations of "unpublish" (switch permissions back to read/write from read/execute) for mmap'd code memory on all our platforms.- Infrastructure in the frame-tables (debug info) metadata producer and parser to record "breakpoint patches".- A tweak to the NOP metadata packaged with the `MachBuffer` to allow multiple NOP sizes. This lets us use one 5-byte NOP on x86-64, for example (did you know x86-64 had these?!) rather than five 1-byte NOPs.This PR also implements single-stepping with a global-per-`Store` flag,because at this point why not; it's a small additional bit of logic todo *all* patches in all modules registered in the `Store` when that flagis enabled.A few realizations for future work:- The need for an introspection API available to a debugger to see the modules within a component is starting to become clear; either that, or the "module and PC" location identifier for a breakpoint switches to a "module or component" sum type. Right now, the tests for this feature use only core modules. Extending to components should not actually be hard at all, we just need to build the API for it.- The interaction between inlining and `patchable_call` is interesting: what happens if we inline a `patchable_call` at a `try_call` callsite? Right now, we do *not* update the `patchable_call` to a `try_call`, because there is no `patchable_try_call`; this is fine in the Wasmtime embedding in practice because we never (today!) throw exceptions from a breakpoint handler. This does suggest to me that maybe we should make patchability a property of any callsite, and allow try-calls to be patchable too (with the same restriction about no return values as the only restriction); but happy to discuss that one further.* Add missing debug.wat disas test.* Review feedback.* Fix comment on `CodeMemory::text_mut`.* Review feedback.* Review feedback: abort process on failure to re-apply executable permissions.* Implement icache flush for aarch64.This appears to be necessary as we otherwise see a failure in CI onmacOS/aarch64 that is consistent with patched-in breakpoint calls stillbeing incorrectly cached after we remove them and republish the code.There is a longstanding issue in #3310 tracking proper icache coherencehandling on aarch64. We implemented this for Linux with the `membarrier`syscall but never did so for macOS. Maybe this is the first point atwhich it matters, because code was always loaded at new addresses (hencedid not have coherence issues because nothing would have been cached)previously.prtest:full* Review feedback: use `next_multiple_of`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

99ecf728 - Debug: create private code memories per store when debugging is enabled. (#12051)

Wed, 03 Dec 2025 01:18:00 +0000

Debug: create private code memories per store when debugging is enabled. (#12051)* Debug: create private code memories per store when debugging is enabled.This will allow patching code to implement e.g. breakpoints. (That is,for now the copies are redundant, but soon they will not be.)This change follows the discussion [here] and offline to define a fewtypes that better encapsulate the distinction we want to enforce.Basically, there is almost never a bare `CodeMemory`; they are alwayswrapped in an `EngineCode` or `StoreCode`, the latter being a per-storeinstance of the former. Accessors are moved to the relevant place sothat, for example, one cannot get a pointer to a Wasm function's bodywithout being in the context of a `Store` where the containing modulehas been registered. The registry then returns a `ModuleWithCode` thatboxes up a `Module` reference and `StoreCode` together for cases wherewe need both the metadata from the module and the raw code to derivesomething.The only case where we return raw code pointers to the `EngineCode`directly have to do with Wasm-to-array trampolines: in some cases, e.g.`InstancePre` pre-creating data structures with references to hostfunctions, it breaks our expected performance characteristics to makethe function pointers store-specific. This is fine as long as theWasm-to-array trampolines never bake in direct calls to Wasm functions;the strong invariant is that Wasm functions never execute from`EngineCode` directly. Some parts of the component runtime would alsohave to be substantially refactored if we wanted to do away with thisexception.The per-`Store` module registry is substantially refactored in this PR.I got rid of the modules-without-code distinction (the case where amodule only has trampolines and no defined functions still works fine),and organized the BTreeMaps to key on start address rather than endaddress, which I find a little more intuitive (one then queries with thedual to the range -- 0-up-to-PC and last entry found).[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812* Review feedback: do not assume a reasonable code alignment; error when it cannot be known* Review feedback: fail properly in profiler when we are cloning code* Fix guest-profiler C API.* Review feedback: make private-code representation impossible in non-debugging-support builds.* Add TODO comment referencing issue for cloning only .text.* clang-format* Review feedback: add back Component::image_range.* Review feedback: error on registering profiling metadata when debug is enabled.* rustfmt* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

02155232 - Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

Wed, 15 Oct 2025 00:03:52 +0000

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.This PR implements ideas from the [recent RFC] to serve as the basisfor Wasm (guest) debugging: it adds a stackslot to each functiontranslated from Wasm, stores to replicate Wasm VM state in thestackslot as the program runs, and metadata to describe the format ofthat state and allow reading it out at runtime.As an initial user of this state, this PR adds a basic "stack view"API that, from host code that has been called from Wasm, can examineWasm frames currently on the stack and read out all of their localsand stack slots.Note in particular that this PR does not include breakpoints,watchpoints, stepped execution, or any sort of user interface for anyof this; it is only a foundation.This PR still has a few unsatisfying bits that I intend to address:- The "stack view" performs some O(n) work when the view is initially taken, computing some internal data per frame. This is forced by the current design of `Backtrace`, which takes a closure and walks that closure over stack frames eagerly (rather than work as an iterator). It's got some impressive iterator-chain stuff going on internally, so refactoring it to the latter approach might not be *too* bad, but I haven't tackled it yet. A O(1) stack view, that is, one that does work only for frames as the host API is used to walk up the stack, is desirable because some use-cases may want to quickly examine e.g. only the deepest frame (say, running with a breakpoint condition that needs to read a particular local's value after each step).- It includes a new `Config::compiler_force_inlining()` option that is used only for testing that we get the correct frames after inlining. I couldn't get the existing flags to work on a Wasmtime config level and suspect there may be an existing bug there; I will try to split out a fix for it.This PR renames the existing `debug` option to `native_debug`, todistinguish it from the new approach.[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44* Update to new APIs on Cranelift side.* Test update.* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.* Convert to iterator form.* Fix path in native-debug tests (debug -> native_debug rename).* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.* Add missing assert.* Use builtin knob for forcing intra-module inlining instead.* Review feedback:- Make StackView own the current frame rather than handing it out. This prevents the current frame (`FrameView`) from walking away and hiding somewhere it shouldn't, to be used unsoundly later.- Assert no-GC during stack walk.* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.* Review feedback: avoid downcasting funcs twice.* Add debug feature to `wasmtime` crate's defaults.* Review feedback: u32s for local and stack indices in debug host API.* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.* Remove some `srcloc` plumbing in Wasm translator.* Rename native-debug back to debug, and make the new thing "guest debugging".* rustfmt in debugging test.* fix disas test after guest-debug CLI option rename.* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.* Review feedback: update doc comment on `Config::guest_debug`.* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.* Review feedback: miscellaneous comments.* Review comment: fix wording in safety conditions.* revert wasi-common submodule update* Properly root values in debug frame slots.Fixes #11841.* Fix non-`debug`-feature build.* Review feedback: naming.* Ignore tests that compile modules in miri. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

4fcfe17a - Refactor the representation of `Func` (#10897)

Mon, 02 Jun 2025 23:55:52 +0000

Refactor the representation of `Func` (#10897)* Refactor the representation of `Func`This commit rewrites the internals of `wasmtime::Func`. The `Stored`type is no longer used meaning that it's now free to create a`wasmtime::Func` at any time. It is effectively a store-tagged`NonNull`. This required a few internal changes to howfunctions are passed around:* Previously the insertion of a `wasm_call`-less `VMFuncRef` was deferred until the raw pointer was loaded. Now the insertion happens immediately as soon as the function is placed within a store. This is done to ensure that a `Func` corresponds to one exact `VMFuncRef` and that's it, and lazily filled in versions within the store are still lazily filled in but they're more eagerly allocated. This isn't expected to have much of an impact perf-wise since all these lazily allocated functions were already almost guaranteed to get lazily allocated anyway.* Filling in "holes" in `VMFuncRef`, notably the `wasm_call` field, no longer happens lazily when the `VMFuncRef` is demanded. Instead during instantiation a pass is made to fill in holes with the new module being instantiated (after registration). Additionally when a lazily-allocated `VMFuncRef` is created the module registry is checked immediately. This means that all store-local `VMFuncRef` values are either filled in immediately or filled in during instantiation. This notably means that the previous logic in `Func::vmimport` is now "just" an `.unwrap()` with a lot of comments saying why the unwrap shouldn't panic.* To implement this commit a previous optimization for the `Func` API was removed as well, namely `Func::call` will become slower after this commit. The `Func::call` API is a dynamically-typed API which requires run-time type-checking of arguments. Previously a `FuncType` was loaded into a cache once-per-`Func` which helped amortize the cost of using `Func::call` repeatedly. Now, though, there's no natural place to put such a cache since `Func` no longer has dedicated storage within a `Store`. Historically this optimization was added for the C API before the `*_call_unchecked` APIs existed, but nowadays the `*_call_unchecked` APIs should suffice for performance-critical applications where needed. In the future it might also be possible to have a hash map in the `Store` of a `VMSharedTypeIndex` to `FuncType` which is lazily populated based on calls to `Func::call`, but that feels a bit overkill nowadays for a possibly rarely-used map.* The no-longer-necessary `RootedHostFunc` type is now gone as its unsafety and various contracts are subsumed by other preexisting `unsafe` blocks.* The specific drop order between `StoreOpaque::store_data` and `StoreOpaque::rooted_host_funcs` is removed. The `rooted_host_funcs` field now lives in the `func_refs` field and the `FuncKind` type, where the destructors came from before, is no more.* The `func_refs` field has grown storage locations for a variety of "keep this thing alive as long as the store" related to functions and such.Closes #10868* Remove mutability from locations that no longer need it* Update crates/wasmtime/src/runtime/func.rsCo-authored-by: Nick Fitzgerald * Update crates/wasmtime/src/runtime/store/func_refs.rsCo-authored-by: Nick Fitzgerald ---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

c22b3cb9 - Reuse Wasm linear memories code for GC heaps (#10503)

Fri, 11 Apr 2025 21:15:55 +0000

Reuse Wasm linear memories code for GC heaps (#10503)* Reuse code for Wasm linear memories for GC heapsInstead of bespoke code paths and structures for Wasm GC, this commit makes itso that we now reuse VM structures like `VMMemoryDefinition` and bounds-checkinglogic. Notably, we also reuse all the associated bounds-checking optimizationsand, when possible, virtual-memory techniques to completely elide them.Furthermore, this commit adds support for growing GC heaps, reusing themachinery for growing memories, and makes it so that GC heaps always start outempty. This allows us to properly delay allocating the GC heap's storage until aGC object is actually allocated.Fixes #9350* fix c api compilation* use assert_contains* remove no-longer-necessary extra memory config from limiter tests* Helper for retry-after-maybe-async-gc in libcalls* Clean up some comments* fix wasmtime-fuzzing and no-gc compilation* fix examples* fix no-gc+compiler build* fix build without pooling allocator* fix +cranelift +gc-drc -gc-null builds* fix table hash key stability test* fix oracle usage of `ExternRef::new`* fix +gc -gc-null -gc-drc build* fix wasmtime-fuzzing* make `StorePtr` wrap a `NonNull`* Fix some doc tests* Remove some unnecessary retry helpers now that `FooRef::new` will auto-gc* fix things after rebase* Reorganize collection/growth methods for GC heap* rename BoundsCheck variants* fix cfg'ing of gc only code* Fix doc tests* fix one more gc cfg* disable GC heap OOM test on non-64-bit targets List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

a727985c - Enable warnings if `gc` is disabled (#10149)

Thu, 30 Jan 2025 16:55:15 +0000

Enable warnings if `gc` is disabled (#10149)* Enable warnings if `gc` is disabledContinuation of work in #10131. This additionally handles turning off`gc-null` and `gc-drc` and the various combinations within.* Fix some more warnings* Fix a feature combo build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

94f21bc9 - Enable warnings if `coredump` is disabled (#10135)

Tue, 28 Jan 2025 17:17:19 +0000

Enable warnings if `coredump` is disabled (#10135)Continuation of work in #10131 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

0058cb78 - pulley: Get strings.wast test passing (#9801)

Thu, 12 Dec 2024 16:34:58 +0000

pulley: Get strings.wast test passing (#9801)* pulley: Get `strings.wast` test passingNeeded the `imul` CLIF instruction to get implemented so 32/64-bitmultiplication have now been added.cc #9783* Flag test as now passing List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

1f812627 - Test Pulley on CI on 32-bit architectures (#9745)

Fri, 06 Dec 2024 20:57:40 +0000

Test Pulley on CI on 32-bit architectures (#9745)This commit extends our CI for i686 and armv7 to test the Pulleybackend, namely the full `*.wast` test suite as well as the `wasmtime`crate itself. Note that many `*.wast` tests are still expected to failat this time.This involved fixing a number of 32-vs-64 bit issues throughout the testsuite in various location in this commit. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

70a37939 - Support executing Pulley in Wasmtime (#9744)

Fri, 06 Dec 2024 20:23:55 +0000

Support executing Pulley in Wasmtime (#9744)* Support executing Pulley in WasmtimeThis commit is the initial implementation of executing the Pulleyinterpreter from the `wasmtime` crate. This gives access to all of the`wasmtime` crate's runtime APIs backed by execution of bytecode inPulley. This builds on the previous PRs I've been making for support inPulley to culminate in testing on CI in this PR. This PR handles somefinal tidbits related to producing a runnable image that can beinterpreted by the `wasmtime` crate such as:* Pulley compilation artifacts are no longer marked as natively executable, just read-only.* Pulley compilation artifacts include wasm-to-array trampolines like normal platforms (removes a pulley special-case).* Dispatch of host calls from Pulley to the Wasmtime runtime are implemented.* Pulley's list of panicking wasm features is slimmed down as most are covered by "this lowering isn't supported" errors.* Execution of wasm code now has an `if` to see whether Pulley is enabled within a `Store` or not.* Traps and basic "unwinding" of the pulley stack are implemented (e.g. a "pulley version" of `setjmp` and `longjmp`, sort of)* Halting the interpreter has been refactored to help shrink the size of `ControlFlow` and handle metadata with each done state.Some minor refactorings are also included here and there along with afew fixes here and there necessary to get tests passing.The next major part of this commit is updates to our `wast` test suiteand executing all `*.wast` files. Pulley is now executed by default forall files as a new execution engine. This means that all platforms in CIwill start executing Pulley tests. At this time almost all tests areflagged as "expected to fail" but there are a small handful ofallow-listed tests which are expected to pass. This exact list willchange over time as CLIF lowerings are implemented and the interpreteris extended.Follow-up PRs will extend the testing strategy further such as:* Extending `#[wasmtime_test]` to include Pulley in addition to Winch.* Getting testing set up on CI for 32-bit platforms.prtest:full* Fix pulley fuzz build* Fix clippy lints* Shuffle around some `#[cfg]`'d code* Remove unused imports* Update feature sets testing MIRIEnable pulley for wasmtime/wasmtime-cli and also enable all features forwasmtime-environ* Round up pulley's page size to 64k* Skip pulley tests on s390x for now* Add a safety rail for matching a pulley target to the host* Fix more pulley tests on s390x* Review comments* Fix fuzz build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

d3132c9d - Add a `signals-based-traps` Cargo compile-time feature (#9614)

Tue, 19 Nov 2024 19:21:36 +0000

Add a `signals-based-traps` Cargo compile-time feature (#9614)* Gate signal handlers behind a new Cargo featureThis commit adds a new on-by-default Cargo feature to the `wasmtime`crate named `signals-based-traps`. This is modeled after the`Config::signals_based_traps` configuration at runtime and can be usedto statically disable the use of signal handlers in Wasmtime. Thisnotably reduces the number of platform dependencies that Wasmtime hasand provides a mode of avoiding relying on signals altogether.This introduces a new `MallocMemory` which is a linear memory backed bythe system allocator. This new type of memory is enabled when virtualmemory guards are disabled and signals-based-traps are disabled. Thismeans that this new type of memory will be candidate for fuzzing forexample.prtest:full* Fix rebase conflict* Refactor `MmapVec` documentation and representation* Remove no-longer-needed `Arc`* Document it may be backed by `Vec` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

8ea25906 - Remove the `wasmtime::runtime::vm::ModuleInfo[Lookup]` traits (#9286)

Thu, 19 Sep 2024 19:52:53 +0000

Remove the `wasmtime::runtime::vm::ModuleInfo[Lookup]` traits (#9286)* Remove the `wasmtime::runtime::vm::ModuleInfo` traitThis harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We cansimply use `wasmtime::Module` these days.* Rename `wasmtime::runtime::vm::ModuleInfoLookup::lookup` to `lookup_module_by_pc`This will make removing `ModuleInfoLookup` easier in subsequent commits.* Remove the `ModuleInfoLookup` traitThis harkens back to the `wasmtime` vs `wasmtime-runtime` crate split. We cansimply use the `ModuleRegistry` directly now.* cargo fmt List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

66dfa363 - wasmtime: Remove GET_WASM_TRAP indirection (#8949)

Mon, 15 Jul 2024 15:39:00 +0000

wasmtime: Remove GET_WASM_TRAP indirection (#8949)In the past, the wasmtime-runtime crate couldn't directly call`get_wasm_trap` because the registry of loaded modules was in thewasmtime crate, so it called through a global function pointerregistered with `init_traps` instead.Since the two crates were merged in #8501, we no longer need thisindirection.While I'm here, I've also split the former `get_wasm_trap` function intotwo parts: `lookup_code` finds a loaded module that had been previouslyregistered with `register_code`, and the `lookup_trap_code` step is nowdone by a helper on `CodeMemory`. This makes the module registry morebroadly useful.I also simplified the code lookup step in two ways:- I removed a redundant check from the code lookup. `BTreeMap::range` will only return entries where `end >= pc`, so the `end < pc` condition is always false.- I used checked_sub instead of writing both the comparison and subtraction explicitly. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

2835a34b - Remove the `ModuleRuntimeInfo` trait (#8778)

Wed, 12 Jun 2024 17:49:54 +0000

Remove the `ModuleRuntimeInfo` trait (#8778)Replace it with an `enum` of the two possibilities that it can be. Thisremoves the need to have a trait dispatch indirection in the `vm`module. Previously this was required as `wasmtime-runtime` was aseparate crate, but now it's no longer required. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

1d11b265 - Remove the native ABI calling convention from Wasmtime (#8629)

Fri, 17 May 2024 04:28:11 +0000

Remove the native ABI calling convention from Wasmtime (#8629)* Remove the native ABI calling convention from WasmtimeThis commit proposes removing the "native abi" calling convention usedin Wasmtime. For background this ABI dates back to the origins ofWasmtime. Originally Wasmtime only had `Func::call` and eventually Iadded `TypedFunc` with `TypedFunc::call` and `Func::wrap` for a fasterpath. At the time given the state of trampolines it was easiest to callWebAssembly code directly without any trampolines using the native ABIthat wasm used at the time. This is the original source of the nativeABI and it's persisted over time under the assumption that it's fasterthan the array ABI due to keeping arguments in registers rather thanspilling them to the stack.Over time, however, this design decision of using the native ABI has notaged well. Trampolines have changed quite a lot in the meantime and it'sno longer possible for the host to call wasm without a trampoline, forexample. Compilations nowadays maintain both native and arraytrampolines for wasm functions in addition to host functions. There's alarge split between `Func::new` and `Func::wrap`. Overall, there's quitea lot of weight that we're pulling for the design decision of using thenative ABI.Functionally this hasn't ever really been the end of the world.Trampolines aren't a known issue in terms of performance or code size.There's no known faster way to invoke WebAssembly from the host (orvice-versa). One major downside of this design, however, is that`Func::new` requires Cranelift as a backend to exist. This is due to thefact that it needs to synthesize various entries in the matrix of ABIswe have that aren't available at any other time. While this is itselfnot the worst of issues it means that the C API cannot be built withouta compiler because the C API does not have access to `Func::wrap`.Overall I'd like to reevaluate given where Wasmtime is today whether itmakes sense to keep the native ABI trampolines. Sure they're supposed tobe fast, but are they really that much faster than the array-call ABI asan alternative? This commit is intended to measure this.This commit removes the native ABI calling convention entirely. Forexample `VMFuncRef` is now one pointer smaller. All of `TypedFunc` nowuses `*mut ValRaw` for loads/stores rather than dealing with ABIbusiness. The benchmarks with this PR are:* `sync/no-hook/core - host-to-wasm - typed - nop` - 5% faster* `sync/no-hook/core - host-to-wasm - typed - nop-params-and-results` - 10% slower* `sync/no-hook/core - wasm-to-host - typed - nop` - no change* `sync/no-hook/core - wasm-to-host - typed - nop-params-and-results` - 7% fasterThese numbers are a bit surprising as I would have suspected no changein both "nop" benchmarks as well as both being slower in theparams-and-results benchmarks. Regardless it is apparent that this isnot a major change in terms of performance given Wasmtime's currentstate. In general my hunch is that there are more expensive sources ofoverhead than reads/writes from the stack when dealing with wasm values(e.g. trap handling, store management, etc).Overall this commit feels like a large simplification of what wecurrently do in `TypedFunc`:* The number of ABIs that Wasmtime deals with is reduced by one. ABIs are pretty much always tricky and having fewer moving parts should help improve the understandability of the system.* All of the `WasmTy` trait methods and `TypedFunc` infrastructure is simplified. Traits now work with simple `load`/`store` methods rather than various other flavors of conversion.* The multi-return-value handling of the native ABI is all gone now which gave rise to significant complexity within Wasmtime's Cranelift translation layer in addition to the `TypedFunc` backing traits.* This aligns components and core wasm where components always use the array ABI and now core wasm additionally will always use the array ABI when communicating with the host.I'll note that this still leaves a major ABI "complexity" with respectto native functions do not have a wasm ABI function pointer untilthey're "attached" to a `Store` with a `Module`. That's required toavoid needing Cranelift for creating host functions and that property isstill true today. This is a bit simpler to understand though now that`Func::new` and `Func::wrap` are treated uniformly rather than one beingspecial-cased.* Fix miri unsafetyprtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs

81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)

Sat, 04 May 2024 22:02:26 +0000

Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn't enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module/registry.rs