Changes in val.rs

0dbb6f3d - Exceptions: implement C API. (#12861)

Tue, 31 Mar 2026 22:56:28 +0000

Exceptions: implement C API. (#12861)* Exceptions: implement C API.This PR implements C (and C++) API support for Wasm exceptions, onefinal remaining hurdle (aside from fuzz-testing) for making exceptionstier-1 and on-by-default.* Review feedback, and add exnref case to `wasmtime_val_t`.* Review feedback: GC feature guard.* clang-format* add docs to exn.hh.* Remove tag size asserts: broken on 32-bit platforms, but not needed for correctness wrt C struct. List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

adff9d9d - Fix externref/anyref ownership in C/C++ API (#11799)

Tue, 07 Oct 2025 16:36:13 +0000

Fix externref/anyref ownership in C/C++ API (#11799)* Fix externref/anyref ownership in C/C++ APIThis commit is a follow-up to #11514 which was discovered throughfailing tests in the wasmtime-py repository when updating to Wasmtime37.0.0. Effectively a combination of bugs in the Rust API meant that itwasn't possible to use `externref` or `anyref` bindings correctly. TheRust changes in this commit are:* `wasmtime_val_unroot` correctly drops the value now as opposed to effectively being a noop from before (typo of using `as_externref` vs `from_externref`).* `wasmtime_{anyref,externref,val}_t` now have a `Drop` implementation in Rust to correctly drop them if a value in Rust is dropped. This is required to correctly manage memory in the `wasmtime_func_{call,new}` implementations, for example.* `wasmtime_{anyref,externref,val}_clone` no longer have an unnecessary context parameter.* `wasmtime_{anyref,externref,val}_unroot` no longer have an unnecessary context parameter.Changes in the C/C++ APIs are:* `Result::{ok,err}_ref` APIs were added in addition to the preexisting rvalue accessors.* Loading/storing typed arguments now has an overload for `const T&` and `T&&` which behaves differently. Notably transferring ownership for `T&&` and not for `const T&`. This means that passing parameters when calling a wasm function uses `const T&`, but passing results from a host import uses `T&&`.* `TypedFunc::call` now uses `const Params&` instead of `Params` to explicitly specify it doesn't modify the parameters and forces using the `const T&` store method.* `Store::gc` is now a convenience method for `store.context().gc()`* `ExternRef`, `AnyRef`, and `Val` now have ownership semantics and destructors. This matches the spirit of #11514 for Rust but models it in C++ as well. This required filling out move/copy constructors/assignments.* The explicit `ExternRef` now takes `std::any` instead of `T`.* Minor issues related to ownership are fixed in `Val` bindings.Valgrind was used to ensure that there were no leaks for the test suitewhich additionally resulted in a number of `*_delete` calls being addedto tests using the C API (accidental omissions).The original goal of this change was to be a patch release for 37.0.1 toenable updating wasmtime-py to the 37.0.x releases of Wasmtime. In theend though the changes here were broad enough that I no longer feel thatthis is a good idea, so wasmtime-py will be skipping the 37 version ofWasmtime.* Run `clang-format`prtest:full List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

a631d20a - cranelift: stack-switching support (#11003)

Thu, 04 Sep 2025 21:58:01 +0000

cranelift: stack-switching support (#11003)* cranelift: stack-switching supportThis initial commit represents the "pr2" base commit withminimal merge conflicts resolved. Due to OOB conflicts, thiscommit is not functional as-is, but using it as a base inorder to allow for easier reviewing of the delta fromthis commit to what will be used for the PR against upstream.Co-authored-by: Daniel Hillerström Co-authored-by: Paul Osborne * cranelift: stack-switching updates pass 1This first set of changes updates the base pr in order tocompiled and pass basic checks (compile, clippy, fmt) withthe biggest part of the change being to eliminate injectionof tracing/assertions in JIT'ed code.* cranelift: stack-switching: restore original visibility for a few func_environ members* cranelift: stack-switching conditional compilationAt this point, the only bit we really branch on is what wedo in order to avoid problems tying into wasmtime_environ.This is basd on the approach and macro used by the gc code forconverting presence/absence of the cranelift feature flag tocranelift compile time. This is a bit of a half-measure for nowas we still compile most stack-switching code in cranelift, butthis does enough to avoid causing problems with missing definitionsin wasmtime_environ.* cranelift: avoid "as" casts in stack-switchingReplace either with infallible From or fallible, panicingTryFrom alternatives where required.* cranelift: cleanup stack-switching control_effect signaturesAfter removing emission of runtime trace logging and assertions,there were several unused parameters. Remove those from theControlEffect signatures completely.* cranelift: rename stack-switching VMArray to VMHostArrayThis matches a change to the mirrored runtime type inthe upstream changes.* stack-switching: fix typoCo-authored-by: Daniel Hillerström * stack-switching: used Index impl for get_stack_slot_data* stack-switching: use smallvec over vec in several cases* stack-switching: avoid resumetable naming confusion* stack-switching: cleanup unused params from unchecked_get_continuationThe extra parameters here used to be used for emitting runtimeassertions, but with those gone we just had unused paramsand lifetimes, clean those out.* stack_switching: simplify store_data_entries assertion* stack-switching: simplify translate_table_{grow,fill} control flow* stack-switching: remove translate_resume_throw stubThere's already a stub elsewhere and this is not called, whenexceptions are added and it is time to revisit, this methodcan be restored.* stack-switching: compute control_context_size based on target triple* stack-switching: VMHostArrayRef updatesRename VMHostArray -> VMHostArrayRefChange impl to compute address with offset upfront rather thanon each load.* stack-switching: move cranelift code to live under func_environThis matches the directory structure for gc and aids in visibilityfor a few members required by stack-switching code in cranelift.* stack-switching: formatting fix* stack-switching: reduce visibility on a few additional items* stack-switching: simplify contobj fatptr con/de-struction* stack-switching: add disas tests to cover new instructions* stack-switching: fix layout of VMContObjIn the course of the various runtime updates, the layout of theruntime VMContObj got switched around. This resulted in failureswhen doing certain table operations on continuations.This change fixes that layout problem and adds some tests withoffsets to avoid the problem. Due to the way that we interactwith the VMContObj in cranelift, we don't use these offsets outsideof the tests.* Fix formatting of merge conflict resolution* cranelift: remove ir::function::get_stack_slot_dataThis method isn't required as sized_stack_slots is already pub.* stack-switching: reduce visibility of a couple func_environ methods* stack-switching: define VMContObj as two wordsThis change migrates VMContObj and its usages in cranelift and runtimeto work with the VMContObj fat pointer as two words in order to bettertarget different architectures (still gated to x86_64 for now).To support this, a size type was plumbed into the builtins functionsignature types (as is done for component types) that maps tousize.* fixup! stack-switching: define VMContObj as two words* stack-switching: add stub Val::ContRefThis type is not fully complete until continuation/gc integrationis revisited (#10248) but without these changes, test cases arenow failing on panics as we need some representation ofcontinuation references in the runtime Val enumeration.Runtime errors with TODO notes are added for the stubbedcode paths to revisit later.* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: define VMContObj as two wordsprtest:full* stack-switching: don't conflate host and target pointer sizesDisas tests were failing on i686 targeting x86_64 as the size of thehost pointer was leaking into what we were using to do codegenin a few paths. This patch is a bit of a hack as it seems likeusing a generic for T: *mut u8 (as an example) is a bitquestionable. To keep things small, I do a hacky typecheck to mappointers to the target pointer size here.* stack-switching: VMHostArray entry sizes based off env PtrSizeRevisiting the previous commit with an approach that should beless brittle.---------Co-authored-by: Frank Emrich Co-authored-by: Daniel Hillerström List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

9826719a - GC: replace ManuallyRooted with OwnedRooted. (#11514)

Tue, 26 Aug 2025 18:54:25 +0000

GC: replace ManuallyRooted with OwnedRooted. (#11514)* GC: replace ManuallyRooted with OwnedRooted.This implements the ideas from #11445: it replaces `ManuallyRooted`,which requires an explicit unroot action with a mut borrow of the store(making it impossible to implement in a standard `Drop` impl), with`OwnedRooted`, which holds an `Arc` only to a small auxiliary memoryallocation (an `Arc<()>`) and uses this externalized "liveness flag" toallow for a `Store`-less drop. These liveness flags are scanned during a"trim" pass, which happens both when new owned roots are created, andjust before a GC.This should greatly increase safety for host-side users of GC: itprovides a way to have a handle whose ownership works like any otherRust value, alive until dropped. It is still not quite as efficient asLIFO-scoped handles (by analogy, for the same reason thatindividually-freed RAII types are not as efficient as arena allocation),so those remain for efficiency-minded users that have a clear picture ofreference lifetimes.At some later time we may wish to use `OwnedRooted` exclusively in ourpublic APIs rather than `Rooted`, and we may wish to rename `Rooted` to`ScopedRooted`, but I haven't done either of those things yet.I opted to *replace* `ManuallyRooted` rather than add a third kind ofroot, after discussion with fitzgen. One implication of this is that theC API's `anyref` and `externref` types are now 24 or 20 bytes ratherthan 16 (because of the `Arc` pointer), and correspondingly the Valunion grew to that size. I *believe* this is an acceptable tradeoff, butI'm happy to put `ManuallyRooted` back if not.Fixes #11445.* Review feedback.* Fix for riscv32imac: loosen asserts on struct size slightly to allow for different padding.* C API: use a `*const ()` to pass the liveness-flag Arc through C.* Add some additional documentation warning about unrooting in the C API.* Fix size-of test on 32-bit platforms.* New amortized algorithm for root trimming.* core::cmp, not std::cmp* Always set high-water mark, even if eager.* Make val size-assert tolerant of padding bytes in crates/c-api/src/val.rs too. List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

eaa4632e - Implement exception objects. (#11230)

Tue, 15 Jul 2025 17:15:35 +0000

Implement exception objects. (#11230)* WIP: Working exception objects* Clean build with gc disabled (`cargo check -p wasmtime --no-default-features --features runtime`).* Review feedback.* Stub out C-API support.* Fix Clippy complaints.* Fix dead-code warning in c-api build.* Actually fix 27->26 reserved bit rename and test.* Fix exnref doc-test.* fix fuzzing build* fix feature-flagging on Instance::id* Bless disas test diff due to reserved-bits change.* Review feedback. List of files: /wasmtime-44.0.1/crates/c-api/src/val.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/c-api/src/val.rs

66d5ad3f - Add release binaries for 32-bit platforms (#10025)

Wed, 15 Jan 2025 21:10:59 +0000

Add release binaries for 32-bit platforms (#10025)This commit notably adds release binaries for:* `i686-unknown-linux-gnu` - named `i686-linux`* `i686-pc-windows-msvc` - named `i686-windows`* `armv7-unknown-linux-gnueabihf` - named `armv7-linux`These artifacts all use Pulley for their execution of WebAssembly andhave been added to the tiers listing under tier 3. List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

ae84e6ed - Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)

Thu, 09 Jan 2025 21:05:55 +0000

Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)* Enable `unsafe-attr-outside-unsafe` 2024 edition lintThis commit enables the `unsafe-attr-outside-unsafe` lint in rustc usedin transitioning to the 2024 edition. This requires that the`#[no_mangle]` attribute is replaced in favor of `#[unsafe(no_mangle)]`.This mostly affects the C API of wasmtime and most of the changes hereare a simple search/replace.* Another attribute update* Fix command adapter build List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

77405cc8 - c-api: Remove allocations from `wasmtime_val_t` (#8451)

Wed, 24 Apr 2024 21:38:28 +0000

c-api: Remove allocations from `wasmtime_val_t` (#8451)* c-api: Remove allocations from `wasmtime_val_t`This commit redesigns how GC references work in the C API. previously`wasmtime_{any,extern}ref_t` were both opaque pointers in the C APIrepresented as a `Box`. Wasmtime did not, however, provide the abilityto deallocate just the `Box` part. This was intended to be handled withunrooting APIs but unrooting requires a `wasmtime_context_t` parameter,meaning that destructors of types in other languages don't have asuitable means of managing the memory around the`wasmtime_{any,extern}ref_t` which might lead to leaks.This PR takes an alternate approach for the representation of thesetypes in the C API. Instead of being an opaque pointer they're nowactual structures with definitions in the header file. These structuresmirror the internals in Rust and Rust is tagged to ensure that changesare reflected in the C API as well. This is similar to how`wasmtime_func_t` matches `wasmtime::Func`. This enables embedders tonot need to worry about memory management of these values outside of themanual rooting otherwise required.The hope is that this will reduce the likelihood of memory leaks andotherwise not make it any harder to manage references in the C API.* Run clang-format* Review comments* Replace macros with inline functions* Add explicit accessors/constructors for the C API* Fix C example* Fix doc link* Fix some doc issuesprtest:full* Fix doxygen links List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

c6e4a502 - c-api: Tidy up some `wasmtime_func_t` usage (#8461)

Wed, 24 Apr 2024 18:49:36 +0000

c-api: Tidy up some `wasmtime_func_t` usage (#8461)* c-api: Tidy up some `wasmtime_func_t` usageTry to avoid using a `transmute` in the implementation of the C API andinstead use a `union` like is being done in #8451. Additionally add somehelper functions to the header to work with null funcref values insteadof only documenting the implementation.* Try to fix doxygen List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

9187f2d9 - c-api: Create `RootScope` where necessary (#8374)

Mon, 15 Apr 2024 22:20:32 +0000

c-api: Create `RootScope` where necessary (#8374)* c-api: Create `RootScope` where necessaryThis commit changes the `wasmtime_val_t::{from_val, to_val}` methods totake a `RootScope` instead of any `AsContextMut`. This then required anumber of refactorings in callers to ensure that a `RootScope` wascreated for any function that needed one. This is required to ensurethat GC references in the C API aren't forced to live for the entirelifetime of the store.This additionally added `*_unrooted` variants which do the same thingbut don't require `RootScope`. This was needed for when the C API callsout to the embedder through a function call because a new `RootScope`wouldn't work for return values (they're bound to a scope within theclosure when we want them to outlive the closure). In these situationsthough we know a `RootScope` is already present at the entrypoint.Closes #8367* Review comments List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

dac3bdb0 - c-api: Fix alignment of `wasmtime_val_*` (#8363)

Sun, 14 Apr 2024 21:40:12 +0000

c-api: Fix alignment of `wasmtime_val_*` (#8363)* c-api: Fix alignment of `wasmtime_val_*`This commit fixes an issue where `wasmtime_val_raw_t` had an incorrectalignment. In Rust `ValRaw` contains a `u128` which has an alignment of16 but in C the representation had a smaller alignment meaning that thealignment of the two structures was different. This was seen to causealignment faults when structure were passed from C++ to Rust, forexample.This commit changes the Rust representation of `ValRaw`'s `v128` fieldto do the same as C which is to use `[u8; 16]`. This avoids the need toraise the alignment in C which appears to be nontrivial. Cranelift isappropriately adjusted to understand that loads/stores from `ValRaw` areno longer aligned. Technically this only applies to the `v128` field butit's not too bad to apply it to the other fields as well.* Try alternate syntax for alignof List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

23640b6c - wasmtime-c-api: Add support for GC references in `wasmtime.h` APIs (#8346)

Sat, 13 Apr 2024 18:17:03 +0000

wasmtime-c-api: Add support for GC references in `wasmtime.h` APIs (#8346)Restores support for `externref` in `wasmtime_val_t`, methods for manipulatingthem and getting their wrapped host data, and examples/tests for these things.Additionally adds support for `anyref` in `wasmtime_val_t`, clone/delete methodssimilar to those for `externref`, and a few `i31ref`-specific methods. Also addsC and Rust example / test for working with `anyref`. List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

9204b3a1 - `wasmtime-c-api`: Improve non-support of GC references in `wasm.h` APIs (#8345)

Fri, 12 Apr 2024 15:27:34 +0000

`wasmtime-c-api`: Improve non-support of GC references in `wasm.h` APIs (#8345)* c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIsThis renames some types and adds some type aliases to help us better distinguishbetween `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-relatedtypes. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is relatedto `wasmtime.h`.* `StoreRef` -> `WasmStoreRef`* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases* `StoreData` -> `WasmtimeStoreData`* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`* Introduce the `Wasmtime{Store,Caller}` aliases* c-api: Improve non-support of GC references in `wasm.h` APIsA couple small tweaks: error message improvements, exhaustive matching, etc... List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

420fc3d1 - c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIs (#8344)

Fri, 12 Apr 2024 14:35:48 +0000

c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIs (#8344)This renames some types and adds some type aliases to help us better distinguishbetween `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-relatedtypes. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is relatedto `wasmtime.h`.* `StoreRef` -> `WasmStoreRef`* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases* `StoreData` -> `WasmtimeStoreData`* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`* Introduce the `Wasmtime{Store,Caller}` aliases List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

0fa13013 - Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)

Thu, 04 Apr 2024 00:24:50 +0000

Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)\### The `GcRuntime` and `GcCompiler` TraitsThis commit factors out the details of the garbage collector away from the restof the runtime and the compiler. It does this by introducing two new traits,very similar to a subset of [those proposed in the Wasm GC RFC], although notall equivalent functionality has been added yet because Wasmtime doesn'tsupport, for example, GC structs yet:[those proposed in the Wasm GC RFC]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md#defining-the-pluggable-gc-interface1. The `GcRuntime` trait: This trait defines how to create new GC heaps, run collections within them, and execute the various GC barriers the collector requires. Rather than monomorphize all of Wasmtime on this trait, we use it as a dynamic trait object. This does imply some virtual call overhead and missing some inlining (and resulting post-inlining) optimization opportunities. However, it is *much* less disruptive to the existing embedder API, results in a cleaner embedder API anyways, and we don't believe that VM runtime/embedder code is on the hot path for working with the GC at this time anyways (that would be the actual Wasm code, which has inlined GC barriers and direct calls and all of that). In the future, once we have optimized enough of the GC that such code is ever hot, we have options we can investigate at that time to avoid these dynamic virtual calls, like only enabling one single collector at build time and then creating a static type alias like `type TheOneGcImpl = ...;` based on the compile time configuration, and using this type alias in the runtime rather than a dynamic trait object. The `GcRuntime` trait additionally defines a method to reset a GC heap, for use by the pooling allocator. This allows reuse of GC heaps across different stores. This integration is very rudimentary at the moment, and is missing all kinds of configuration knobs that we should have before deploying Wasm GC in production. This commit is large enough as it is already! Ideally, in the future, I'd like to make it so that GC heaps receive their memory region, rather than allocate/reserve it themselves, and let each slot in the pooling allocator's memory pool be *either* a linear memory or a GC heap. This would unask various capacity planning questions such as "what percent of memory capacity should we dedicate to linear memories vs GC heaps?". It also seems like basically all the same configuration knobs we have for linear memories apply equally to GC heaps (see also the "Indexed Heaps" section below).2. The `GcCompiler` trait: This trait defines how to emit CLIF that implements GC barriers for various operations on GC-managed references. The Rust code calls into this trait dynamically via a trait object, but since it is customizing the CLIF that is generated for Wasm code, the Wasm code itself is not making dynamic, indirect calls for GC barriers. The `GcCompiler` implementation can inline the parts of GC barrier that it believes should be inline, and leave out-of-line calls to rare slow paths.All that said, there is still only a single implementation of each of thesetraits: the existing deferred reference-counting (DRC) collector. So there is abunch of code motion in this commit as the DRC collector was further isolatedfrom the rest of the runtime and moved to its own submodule. That said, this wasnot *purely* code motion (see "Indexed Heaps" below) so it is worth not simplyskipping over the DRC collector's code in review.\### Indexed HeapsThis commit does bake in a couple assumptions that must be shared across allcollector implementations, such as a shared `VMGcHeader` that all objectsallocated within a GC heap must begin with, but the most notable andfar-reaching of these assumptions is that all collectors will use "indexedheaps".What we are calling indexed heaps are basically the three following invariants:1. All GC heaps will be a single contiguous region of memory, and all GC objects will be allocated within this region of memory. The collector may ask the system allocator for additional memory, e.g. to maintain its free lists, but GC objects themselves will never be allocated via `malloc`.2. A pointer to a GC-managed object (i.e. a `VMGcRef`) is a 32-bit offset into the GC heap's contiguous region of memory. We never hold raw pointers to GC objects (although, of course, we have to compute them and use them temporarily when actually accessing objects). This means that deref'ing GC pointers is equivalent to deref'ing linear memory pointers: we need to add a base and we also check that the GC pointer/index is within the bounds of the GC heap. Furthermore, compressing 64-bit pointers into 32 bits is a fairly common technique among high-performance GC implementations[^compressed-oops][^v8-ptr-compression] so we are in good company.3. Anything stored inside the GC heap is untrusted. Even each GC reference that is an element of an `(array (ref any))` is untrusted, and bounds checked on access. This means that, for example, we do not store the raw pointer to an `externref`'s host object inside the GC heap. Instead an `externref` now stores an ID that can be used to index into a side table in the store that holds the actual `Box` host object, and accessing that side table is always checked.[^compressed-oops]: See ["Compressed OOPs" in OpenJDK.](https://wiki.openjdk.org/display/HotSpot/CompressedOops)[^v8-ptr-compression]: See [V8's pointer compression](https://v8.dev/blog/pointer-compression).The good news with regards to all the bounds checking that this scheme impliesis that we can use all the same virtual memory tricks that linear memories useto omit explicit bounds checks. Additionally, (2) means that the sizes of GCobjects is that much smaller (and therefore that much more cache friendly)because they are only holding onto 32-bit, rather than 64-bit, references toother GC objects. (We can, in the future, support GC heaps up to 16GiB in sizewithout losing 32-bit GC pointers by taking advantage of `VMGcHeader` alignmentand storing aligned indices rather than byte indices, while still leaving thebottom bit available for tagging as an `i31ref` discriminant. Should we everneed to support even larger GC heap capacities, we could go to full 64-bitreferences, but we would need explicit bounds checks.)The biggest benefit of indexed heaps is that, because we are (explicitly orimplicitly) bounds checking GC heap accesses, and because we are not otherwisetrusting any data from inside the GC heap, we greatly reduce how badly thingscan go wrong in the face of collector bugs and GC heap corruption. We areessentially sandboxing the GC heap region, the same way that linear memory is asandbox. GC bugs could lead to the guest program accessing the wrong GC object,or getting garbage data from within the GC heap. But only garbage data fromwithin the GC heap, never outside it. The worse that could happen would be if wedecided not to zero out GC heaps between reuse across stores (which is a validtrade off to make, since zeroing a GC heap is a defense-in-depth techniquesimilar to zeroing a Wasm stack and not semantically visible in the absence ofGC bugs) and then a GC bug would allow the current Wasm guest to read old GCdata from the old Wasm guest that previously used this GC heap. But again, itcould never access host data.Taken altogether, this allows for collector implementations that are nearly freefrom `unsafe` code, and unsafety can otherwise be targeted and limited in scope,such as interactions with JIT code. Most importantly, we do not have to maintaincritical invariants across the whole system -- invariants which can't be nicelyencapsulated or abstracted -- to preserve memory safety. Such holisticinvariants that refuse encapsulation are otherwise generally a huge safetyproblem with GC implementations.\### `VMGcRef` is *NOT* `Clone` or `Copy` Anymore`VMGcRef` used to be `Clone` and `Copy`. It is not anymore. The motivation herewas to be sure that I was actually calling GC barriers at all the correctplaces. I couldn't be sure before. Now, you can still explicitly copy a raw GCreference without running GC barriers if you need to and understand why that'sokay (aka you are implementing the collector), but that is something you have toopt into explicitly by calling `unchecked_copy`. The default now is that youcan't just copy the reference, and instead call an explicit `clone` method (not*the* `Clone` trait, because we need to pass in the GC heap context to run theGC barriers) and it is hard to forget to do that accidentally. This resulted ina pretty big amount of churn, but I am wayyyyyy more confident that the correctGC barriers are called at the correct times now than I was before.\### `i31ref`I started this commit by trying to add `i31ref` support. And it grew into thewhole traits interface because I found that I needed to abstract GC barriersinto helpers anyways to avoid running them for `i31ref`s, so I figured that Imight as well add the whole traits interface. In comparison, `i31ref` support ismuch easier and smaller than that other part! But it was also difficult to pullapart from this commit, sorry about that!---------------------Overall, I know this is a very large commit. I am super happy to have somesynchronous meetings to walk through this all, give an overview of thearchitecture, answer questions directly, etc... to make review easier!prtest:full List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

bd2ea901 - Define garbage collection rooting APIs (#8011)

Wed, 06 Mar 2024 00:40:02 +0000

Define garbage collection rooting APIs (#8011)* Define garbage collection rooting APIsRooting prevents GC objects from being collected while they are actively beingused.We have a few sometimes-conflicting goals with our GC rooting APIs:1. Safety: It should never be possible to get a use-after-free bug because the user misused the rooting APIs, the collector "mistakenly" determined an object was unreachable and collected it, and then the user tried to access the object. This is our highest priority.2. Moving GC: Our rooting APIs should moving collectors (such as generational and compacting collectors) where an object might get relocated after a collection and we need to update the GC root's pointer to the moved object. This means we either need cooperation and internal mutability from individual GC roots as well as the ability to enumerate all GC roots on the native Rust stack, or we need a level of indirection.3. Performance: Our rooting APIs should generally be as low-overhead as possible. They definitely shouldn't require synchronization and locking to create, access, and drop GC roots.4. Ergonomics: Our rooting APIs should be, if not a pleasure, then at least not a burden for users. Additionally, the API's types should be `Sync` and `Send` so that they work well with async Rust.For example, goals (3) and (4) are in conflict when we think about how tosupport (2). Ideally, for ergonomics, a root would automatically unroot itselfwhen dropped. But in the general case that requires holding a reference to thestore's root set, and that root set needs to be held simultaneously by all GCroots, and they each need to mutate the set to unroot themselves. That implies`Rc>` or `Arc>`! The former makes the store and GC roottypes not `Send` and not `Sync`. The latter imposes synchronization and lockingoverhead. So we instead make GC roots indirect and require passing in a storecontext explicitly to unroot in the general case. This trades worse ergonomicsfor better performance and support for moving GC and async Rust.Okay, with that out of the way, this module provides two flavors of rootingAPI. One for the common, scoped lifetime case, and another for the rare casewhere we really need a GC root with an arbitrary, non-LIFO/non-scoped lifetime:1. `RootScope` and `Rooted`: These are used for temporarily rooting GC objects for the duration of a scope. Upon exiting the scope, they are automatically unrooted. The internal implementation takes advantage of the LIFO property inherent in scopes, making creating and dropping `Rooted`s and `RootScope`s super fast and roughly equivalent to bump allocation. This type is vaguely similar to V8's [`HandleScope`]. [`HandleScope`]: https://v8.github.io/api/head/classv8_1_1HandleScope.html Note that `Rooted` can't be statically tied to its context scope via a lifetime parameter, unfortunately, as that would allow the creation and use of only one `Rooted` at a time, since the `Rooted` would take a borrow of the whole context. This supports the common use case for rooting and provides good ergonomics.2. `ManuallyRooted`: This is the fully general rooting API used for holding onto non-LIFO GC roots with arbitrary lifetimes. However, users must manually unroot them. Failure to manually unroot a `ManuallyRooted` before it is dropped will result in the GC object (and everything it transitively references) leaking for the duration of the `Store`'s lifetime. This type is roughly similar to SpiderMonkey's [`PersistentRooted`], although they avoid the manual-unrooting with internal mutation and shared references. (Our constraints mean we can't do those things, as mentioned explained above.) [`PersistentRooted`]: http://devdoc.net/web/developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS::PersistentRooted.htmlAt the end of the day, both `Rooted` and `ManuallyRooted` are just taggedindices into the store's `RootSet`. This indirection allows working with Rust'sborrowing discipline (we use `&mut Store` to represent mutable access to the GCheap) while still allowing rooted references to be moved around without tying upthe whole store in borrows. Additionally, and crucially, this indirection allowsus to update the *actual* GC pointers in the `RootSet` and support moving GCs(again, as mentioned above).* Reorganize GC-related submodules in `wasmtime-runtime`* Reorganize GC-related submodules in `wasmtime`* Use `Into` for `Externref::data[_mut]` methods* Run rooting tests under MIRI* Make `into_abi` take an `AutoAssertNoGc`* Don't use atomics to update externref ref counts anymore* Try to make lifetimes/safety more-obviously correctRemove some transmute methods, assert that `VMExternRef`s are the only valid`VMGcRef`, etc.* Update extenref constructor examples* Make `GcRefImpl::transmute_ref` a non-default trait method* Make inline fast paths for GC LIFO scopes* Make `RootSet::unroot_gc_ref` an `unsafe` function* Move Hash and Eq for Rooted, move to impl methods* Remove type parameter from `AutoAssertNoGc`Just wrap a `&mut StoreOpaque` directly.* Make a bunch of internal `ExternRef` methods that deal with raw `VMGcRef`s take `AutoAssertNoGc` instead of `StoreOpaque`* Fix compile after rebase* rustfmt* revert unrelated egraph changes* Fix non-gc build* Mark `AutoAssertNoGc` methods inline* review feedback* Temporarily remove externref support from the C APIUntil we can add proper GC rooting.* Remove doxygen reference to temp deleted function* Remove need to `allow(private_interfaces)`* Fix call benchmark compilation List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

ff93bce0 - Wasmtime: Finish support for the typed function references proposal (#7943)

Tue, 20 Feb 2024 20:33:28 +0000

Wasmtime: Finish support for the typed function references proposal (#7943)* Wasmtime: Finish support for the typed function references proposalWhile we supported the function references proposal inside Wasm, we didn'tsupport it on the "outside" in the Wasmtime embedder APIs. So much of the workhere is exposing typed function references, and their type system updates, inthe embedder API. These changes include:* `ValType::FuncRef` and `ValType::ExternRef` are gone, replaced with the introduction of the `RefType` and `HeapType` types and a `ValType::Ref(RefType)` variant.* `ValType` and `FuncType` no longer implement `Eq` and `PartialEq`. Instead there are `ValType::matches` and `FuncType::matches` methods which check directional subtyping. I also added `ValType::eq` and `FuncType::eq` static methods for the rare case where someone needs to check precise equality, but that is almost never actually the case, 99.99% of the time you want to check subtyping.* There are also public `Val::matches_ty` predicates for checking if a value is an instance of a type, as well as internal helpers like `Val::ensure_matches_ty` that return a formatted error if the value does not match the given type. These helpers are used throughout Wasmtime internals now.* There is now a dedicated `wasmtime::Ref` type that represents reference values. Table operations have been updated to take and return `Ref`s rather than `Val`s.Furthermore, this commit also includes type registry changes to correctly managelifetimes of types that reference other types. This wasn't previously an issuebecause the only thing that could reference types that reference other types wasa Wasm module that added all the types that could reference each other at thesame time and removed them all at the same time. But now that the previouslydiscussed work to expose these things in the embedder API is done, type lifetimemanagement in the registry becomes a little trickier because the embedder mightgrab a reference to a type that references another type, and then unload theWasm module that originally defined that type, but then the user should still beable use that type and the other types it transtively references. Before, wewere refcounting individual registry entries. Now, we still are refcountingindividual entries, but now we are also accounting for type-to-type referencesand adding a new type to the registry will increment the refcounts of each ofthe types that it references, and removing a type from the registry willdecrement the refcounts of each of the types it references, and then recursively(logically, not literally) remove any types whose refcount has now reached zero.Additionally, this PR adds support for subtyping to `Func::typed`- and`Func::wrap`-style APIs. For result types, you can always use a supertype of theWebAssembly function's actual declared return type in `Func::typed`. And forparam types, you can always use a subtype of the Wasm function's actual declaredparam type. Doing these things essentially erases information but is alwayscorrect. But additionally, for functions which take a reference to a concretetype as a parameter, you can also use the concrete type's supertype. Consider aWebAssembly function that takes a reference to a function with a concrete type:`(ref null )`. In this scenario, there is no static`wasmtime::Foo` Rust type that corresponds to that particular Wasm-definedconcrete reference type because Wasm modules are loaded dynamically atruntime. You *could* do `f.typed::, ()>()`, and while that iscorrectly typed and valid, it is often overly restrictive. The only value youcould call the resulting typed function with is the null function reference, butwe'd like to call it with non-null function references that happen to be of thecorrect type. Therefore, `f.typed, ()>()` is also allowed in thiscase, even though `Option` represents `(ref null func)` which is thesupertype, not subtype, of `(ref null )`. This does imply someminimal dynamic type checks in this case, but it is supported for betterergonomics, to enable passing non-null references into the function.We can investigate whether it is possible to use generic type parameters andcombinators to define Rust types that precisely match concrete reference typesin future, follow-up pull requests. But for now, we've made things usable, atleast.Finally, this also takes the first baby step towards adding support for the WasmGC proposal. Right now the only thing that is supported is `nofunc` references,and this was mainly to make testing function reference subtyping easier. Butthat does mean that supporting `nofunc` references entailed also adding a`wasmtime::NoFunc` type as well as the `Config::wasm_gc(enabled)` knob. So weofficially have an in-progress implementation of Wasm GC in Wasmtime after thisPR lands!Fixes https://github.com/bytecodealliance/wasmtime/issues/6455* Fix WAT in test to be valid* Check that dependent features are enabled for function-references and GC* Remove unnecessary engine parameters from a few methodsEver since `FuncType`'s internal `RegisteredType` holds onto its own `Engine`,we don't need these anymore.Still useful to keep the `Engine` parameter around for the `ensure_matches`methods because that can be used to check correct store/engine usage forembedders.* Add missing dependent feature enabling for some tests* Remove copy-paste bit from test* match self to show it is uninhabited* Add a missing `is_v128` method* Short circuit a few func type comparisons* Turn comment into part of doc comment* Add test for `Global::new` and subtyping* Add tests for embedder API, tables, and subtyping* Add an embedder API test for setting globals and subtyping* Construct realloc's type from its index, rather than from scratch* Help LLVM better optimize our dynamic type checks in `TypedFunc::call_raw`* Fix call benchmark compilation* Change `WasmParams::into_abi` to take the whole func type instead of iter of params* Fix doc linksprtest:full* Fix size assertion on s390x List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs

8d7a2b89 - Add support for `v128` to the typed function API (#7010)

Thu, 14 Sep 2023 15:57:34 +0000

Add support for `v128` to the typed function API (#7010)* Add support for `v128` to the typed function APIThis commit adds a Rust type `V128` which corresponds to the wasm`v128` type. This is intended to perhaps one day have accessors forlanes of various sizes but in the meantime only supports conversion backand forth between `u128`. The intention of this type is to allowplatforms to perform typed between to functions that take or return`v128` wasm values.Previously this was not implemented because it's a bit tricky ABI-wise.Typed functions work by passing arguments in registers which requiresthe calling convention to match in both Cranelift and in Rust. Thisshould be the case for supported platforms and the default callingconvention, especially now that the wasm calling convention is separatefrom the platform calling convention. This does mean, however, that thisfeature can only be supported on x86_64 and AArch64. Currently neithers390x nor RISC-V have a means of supporting the vector callingconvention since the vector types aren't available on stable in Rustitself. This means that it's now unfortunately possible to write aWasmtime embedding that compiles on x86_64 that doesn't compile on s390xfor example, but given how niche this feature is that seems like an oktradeoff for now and by the time it's a problem Rust might have nativestable support for vector types on these platforms.prtest:full* Fix compile of C API* Conditionally enable typed v128 tests* Review comments* Fix compiler warnings List of files: /wasmtime-44.0.1/crates/c-api/src/val.rs