Changes in module.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.rs

31f45079 - Do not allocate for `wasmtime::Module::imports` iterator (#12682)

Thu, 26 Feb 2026 23:01:55 +0000

Do not allocate for `wasmtime::Module::imports` iterator (#12682)* Do not allocate for `wasmtime::Module::imports` iterator* Revert "Do not allocate for `wasmtime::Module::imports` iterator"This reverts commit d10da005f9105358fbe71b8610e89a67844b8726.* review feedback List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

601c8b93 - Handle OOM in `Module::deserialize` (#12673)

Wed, 25 Feb 2026 23:29:24 +0000

Handle OOM in `Module::deserialize` (#12673)Part of https://github.com/bytecodealliance/wasmtime/issues/12069 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

7051ab30 - Debugging: add unique-within-store IDs for every entity. (#12645)

Tue, 24 Feb 2026 18:07:42 +0000

Debugging: add unique-within-store IDs for every entity. (#12645)When building an introspection API for use by a debugger, we need away to expose *identity*: that is, to give some way of knowing that agiven `Memory`, `Instance`, etc. is *this* one and not *that* one. Ourhandle types variously have either `Eq` implementations ore.g. `Module::same` for the ones that wrap an `Arc` under-the-covers;but that's not enough to allow a debugger to e.g. build a hashmap forwhatever metadata that it might expose via whatever debuggingprotocol.For maximal generality and flexibility, we should expose the uniqueIDs that already more-or-less exist: for instances, that is theirinstance ID directly; for entities owned by instances, we can build a`u64` with the instance ID in the upper 32 bits and the defined-indexin the lower 32 bits. IDs for all entities except modules areunique-within-a-Store (and this is all that is needed); IDs formodules happen to reuse the `CompiledModuleId` and so areunique-within-an-Engine.I've opted to name these `debug_index_within_store` to scope thefeature and intended use-case clearly, but if there's a desire, Icould easily rename them to simply `index`. I shied away from thathere because I didn't want to give a notion that these indices aresomehow canonical or correspond to some order or other. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

c07c94d2 - Debugging: preserve original Wasm bytecode inside of compiled ELF artifact. (#12636)

Tue, 24 Feb 2026 00:51:29 +0000

Debugging: preserve original Wasm bytecode inside of compiled ELF artifact. (#12636)* Debugging: preserve original Wasm bytecode inside of compiled ELF artifact.This PR adds logic to embed the original core Wasm module(s) from acompilation into a new ELF section, alongside other metadatasections. When a component is compiled, the core Wasms inside arepreserved, accessible by their `StaticModuleIndex`es.The need for this support arises from the guest-debuggerecosystem. Consider either a debugcomponent (bytecodealliance/rfcs#45) or a bespoke debugger in nativecode using Wasmtime's APIs. In either case, the existing APIs tointrospect execution state provide `Module` references for eachinstance from each stack frame, and PC offsets into these `Module`sare the way in which breakpoints are configured. The debugger willsomehow need to associate these `Module`s with the original Wasmbytecode, including e.g. any custom sections containing theproducer-specific ways of encoding debug metadata, to do somethinguseful. In particular also note that the GDB-stub protocol as extendedfor Wasm requires read access directly to the Wasm bytecode (it showsup as part of a "memory map" that is viewed by the standardread-remote-memory command); we can't delegate this requirement to theremote end of the stub connection, but have to handle it in the stubserver that runs inside Wasmtime (as a component or bespoke).We have two main choices: carry the original bytecode all the waythrough the Wasmtime compilation pipeline and present it via`Module::bytecode()`, ready to use; or say that this task isout-of-scope and that the debugger top-half can find it on disksomehow.Unfortunately the latter ("out of scope, find the file") is somewhatat odds with the desired developer experience:- It means that we need some way of mapping a compiled Wasm artifact back to a source Wasm; absent "here's the full bytecode", that means "here's the path to the full bytecode", but that path is an identifier that may not be universally accessible (consider e.g. capabilities/preopens present for a debugger component) or portable (consider e.g. moving the artifact to a different machine). - Or we don't even provide that metadata, and require the user to explicitly specify the same module filename twice -- once to actually run it, and once as an argument to the debugger.- It means that we should account for stale artifacts and mark the mismatch somehow; e.g. if the user starts debugging with Wasmtime, either from a `.cwasm` on disk or with one produced in-memory just for this run, and then subsequently rebuilds their source `.wasm`, we no longer have a reference for it. (The same problem exists one level up if source code is edited, but source to a Wasm producer toolchain is definitely out-of-scope for Wasmtime.)- It means that special logic is required in the case of components to map a module back to a specific component section (we would essentially have to expose the static module IDs, then require the debugger top-half to re-implement our exact flattening algorithm to find that core module).The permissions issue alone was enough to convince me that we shoulddo something better than providing a filename (why should we have toauthorize the adapter to read the user's filesystem?) but all of theother benefits -- ensuring an exact match and ensuring perfectavailability -- are a nice bonus. The main downside is making the`.cwasm` larger (possibly substantially so), but this overhead is onlypresent when enabling guest-debugging, the data has to be presentanyway, and this is likely not a dealbreaker.* miri ignore tests with compilation* Review feedback. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

b298f375 - RR #2: Sha256 checksum for components (#12576)

Fri, 13 Feb 2026 21:11:58 +0000

RR #2: Sha256 checksum for components (#12576)* Add sha256 checksum for component for record/replay consistency* Move sha2 crate as workspace dependency* Run checksum digest only on recording configs* Fix CI error and restructure from_binary List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

1f16b28f - Refactor `String` usage in `wasmtime_environ::Module` (#12565)

Thu, 12 Feb 2026 21:27:05 +0000

Refactor `String` usage in `wasmtime_environ::Module` (#12565)* Refactor `String` usage in `wasmtime_environ::Module`Do not hold regular `String`s; instead use our own OOM-handling`wasmtime_core::alloc::String` or, even better, an interned `Atom` from the`StringPool`.Also avoid `IndexMap`, as it doesn't handle OOMs.* Use OOM-handling `IndexMap` in `wasmtime_environ::Module`* review feedback List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

9e3b5ee5 - Refactor the `TypeRegistry` to partially handle OOM (#12500)

Tue, 03 Feb 2026 18:00:18 +0000

Refactor the `TypeRegistry` to partially handle OOM (#12500)* Refactor the `TypeRegistry` to partially handle OOMThis refactors the type registry to be more "columnar" when registering thetypes within a rec group, so that we* Add all the types themselves* Add the rec group metadata for all types in the rec group* Add the supertypes metadata for all types in the rec group* Etc...Instead of adding one type, its rec group metadata, its supertypes metadata,etc... and then moving on to the next type.This makes it easier to pre-reserve space and roll back changes on OOM errors.This is part of https://github.com/bytecodealliance/wasmtime/issues/12069 andthe OOM handling effort, but doesn't fully get the `TypeRegistry` to a placewhere it handles all OOMs yet. There are a couple places that need furtherwork (usage of hash sets and `Cow::into_owned`) which I have marked with `TODO`comments. In the meantime, I found this to be a nice refactoring of the existingfunctionality, so I think it can land as-is.* review feedback List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

5566d520 - Fix `Module::image_range` to include non-text part of module. (#12302)

Fri, 09 Jan 2026 19:05:54 +0000

Fix `Module::image_range` to include non-text part of module. (#12302)* Fix `Module::image_range` to include non-text part of module.This method is informational for embedders to be able to, for example,ensure an image in memory is `mlock`'d (not swapped out). In therefactors around the StoreCode/EngineCode split, I mistakenly redefinedthis to only the text section. This is not a Wasm execution correctnessissue but may lead to performance issues if an embedder relies on thisbehavior. This PR fixes the definition.* Components as well as core modules.* Ignore new tests in miri. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.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.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.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.rs

17060bb1 - Add missing `gc` feature gates (#12074)

Mon, 24 Nov 2025 16:58:11 +0000

Add missing `gc` feature gates (#12074)* add more `gc` feature gates* test debug gc feature combination List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.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.rs

1806c265 - Lookup functions in the text section by `FuncKey` at runtime (#11630)

Mon, 15 Sep 2025 22:35:40 +0000

Lookup functions in the text section by `FuncKey` at runtime (#11630)This commit refactors our metadata, treating compiled functions homogeneouslyand removing the need to add new tables to places like `CompiledModuleInfo`whenever we add a new kind of function. This also simplifies the process ofconstructing the metadata for a final, linked compilation artifact. Finally, itpaves the way to doing gc-sections during our linking process (which would giveus smaller code sizes by removing functions that have been inlined into everycaller, for example) as we now allow holes in certain types of function indexspaces that were previously always densely populated.We have two kinds of index spaces:1. Mostly-dense index spaces, which take O(max_index) space and provide O(1)lookups.2. Sparse index spaces, which take O(num_members) space and provideO(log n) lookups.Most of our function index spaces are currently dense, but we can tweak that inthe future if necessary.Furthermore, code size of `.cwasm` binaries has shrunk very slightly with thisrefactoring. Consider `spidermonkey.wasm`'s compiled `.cwasm`:* Size before: 218756 `.wasmtime.info` section bytes, 20052632 total bytes* Size after: 213761 `.wasmtime.info` section bytes, 20047640 total bytesThat is a 2.28% reduction on the size of the `.wasmtime.info` section, or a0.025% reduction total.However, we previously did a single metadata lookup to get the location of botha Wasm function itself and its array-to-Wasm trampoline at the same time, and inthe new version of the code two lookups are performed. This is slightly slower,as shown in our call-indirect micro-benchmark that combines lazy tableinitialization (which delays looking up the function element's location untilruntime) with indirect-calling each table element exactly once (which defeatsthe amortization of that lookup). So this micro-benchmark is both synthetic andthe worst-case scenario for this commit's change: we are measuring, as much aswe can, *only* the force-initialization-of-a-lazy-funcref-table-slot path.Ultimately, I believe that the simplification is worth the regression in thismicro-benchmark.

call-indirect micro-benchmarks results

```call-indirect/same-callee/table-init-lazy/65536-calls time: [152.77 µs 154.92 µs 157.39 µs] thrpt: [416.40 Melem/s 423.04 Melem/s 428.99 Melem/s] change: time: [−13.749% −10.205% −6.2864%] (p = 0.00 < 0.05) thrpt: [+6.7081% +11.365% +15.941%] Performance has improved.Found 13 outliers among 100 measurements (13.00%) 8 (8.00%) high mild 5 (5.00%) high severecall-indirect/different-callees/table-init-lazy/65536-calls time: [4.3564 ms 4.4641 ms 4.5843 ms] thrpt: [14.296 Melem/s 14.681 Melem/s 15.044 Melem/s] change: time: [+38.134% +44.404% +50.927%] (p = 0.00 < 0.05) thrpt: [−33.743% −30.750% −27.606%] Performance has regressed.Found 5 outliers among 100 measurements (5.00%) 2 (2.00%) high mild 3 (3.00%) high severecall-indirect/same-callee/table-init-strict/65536-calls time: [144.91 µs 148.41 µs 152.02 µs] thrpt: [431.10 Melem/s 441.58 Melem/s 452.24 Melem/s] change: time: [−13.665% −10.470% −7.2626%] (p = 0.00 < 0.05) thrpt: [+7.8313% +11.694% +15.828%] Performance has improved.Found 4 outliers among 100 measurements (4.00%) 1 (1.00%) high mild 3 (3.00%) high severecall-indirect/different-callees/table-init-strict/65536-calls time: [195.18 µs 200.67 µs 206.49 µs] thrpt: [317.38 Melem/s 326.59 Melem/s 335.77 Melem/s] change: time: [−15.936% −11.568% −7.0835%] (p = 0.00 < 0.05) thrpt: [+7.6235% +13.081% +18.957%] Performance has improved.Found 5 outliers among 100 measurements (5.00%) 5 (5.00%) high mild```

List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

2d25f862 - WebAssembly exception-handling support. (#11326)

Thu, 21 Aug 2025 02:55:44 +0000

WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn't support the host at all then there's noneed to run it. Actually running it could misinterpret `CraneliftNative`as "run with pulley" otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

b500820e - Add support for the Linux PAGEMAP_SCAN ioctl (#11372)

Fri, 08 Aug 2025 16:19:07 +0000

Add support for the Linux PAGEMAP_SCAN ioctl (#11372)* WIP: use the pagemap_scan ioctl to selectively reset an instance's dirty pages* Less hacky, and supporting tables, too* Bugfixes* WIP: memcpy instead of pread* Refactor support for pagemap* Don't hold a raw pointer to the original data, plumb through an `Arc` to have a safe reference instead.* Update pagemap bindings to latest version of abstraction written.* Include pagemap-specific tests.* Use a `PageMap` structure created once-per-pool instead of a static-with-a-file.* Refactor to use the "pagemap path" unconditionally which blends in the keep_resident bits.* Improve safety documentationprtest:full* Fix some lints* Skip ioctl tests when it's not supported* Fix a memory leak by moving impls around* Fix no vm build* Review comments* Add more pagemap-specific documentation* Add more docs, refactor implementation slightly* Improve `category_*` docsBasically forward to the Linux kernel source itself.* Fix compile* Make pagemap integration resilient across forks* Fix non-pooling-allocator-build* Fix portability issues of new test* Actually use config on macos---------Co-authored-by: Till Schneidereit List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

0f457fad - Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)

Fri, 25 Jul 2025 18:22:03 +0000

Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)* Raise `unsafe_op_in_unsafe_fn` further in WasmtimeNow it's at `wasmtime::runtime`, not just `wasmtime::runtime::vm`.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.rs

e012eeda - Remove Stored from wasmtime::Instance (#10909)

Tue, 03 Jun 2025 14:59:25 +0000

Remove Stored from wasmtime::Instance (#10909)* Remove the "export cache" on instancesThis is now a relic of the past now that conversion from the internalto external representation of Wasmtime items is free. This iseffectively dead code that is no longer needed.* Remove `Stored` from `wasmtime::Instance`Powered by all previous commits this is a near-trivial change where an`Instance` is now more-or-less "just" an `InstanceId`. Additionally the`host_state: Box` is no longer needed within `vm::Instance` sothat was removed as well. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/module.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.rs