Changes in async_functions.rs

aedc5480 - Added a thread_local guard to trigger dtor hook before fibers are used (#12426)

Wed, 28 Jan 2026 20:12:14 +0000

Added a thread_local guard to trigger dtor hook before fibers are used (#12426)* Added a thread_local guard to trigger dtor hook before fibers are used* Add a test for async function that use a tls variable with a destructor List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

cc8d04f4 - Remove need for explicit `Config::async_support` knob (#12371)

Fri, 23 Jan 2026 02:46:45 +0000

Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

3d67b75e - Add a dummy impl of fibers for Miri (#11009)

Wed, 11 Jun 2025 00:47:47 +0000

Add a dummy impl of fibers for Miri (#11009)* Add a dummy impl of fibers for MiriThis commit extends the `wasmtime-internal-fiber` crate with animplementation for Miri. Previously this was entirely unsupportedbecause fibers use inline assembly. The implementation with Miri spawnsa separate thread and keeps it in a suspended state with locks to modela suspended stack. This technically isn't correct because TLS variableswill be wrong, but it's "correct enough" for our usage in Wasmtime. Inthe end this enables running more tests in Miri which is always a goodthing, and a number of loose odds and ends were cleaned up relate to ourunsafe management of async state.* Apply suggestions from code reviewCo-authored-by: Pat Hickey ---------Co-authored-by: Pat Hickey List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

d41b0a71 - Use `Waker::noop` from Rust 1.85 (#10804)

Thu, 22 May 2025 16:19:12 +0000

Use `Waker::noop` from Rust 1.85 (#10804)Now possible after #10785 List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

f81c0dc0 - Add `T: 'static` to `Store` (#10760)

Tue, 13 May 2025 05:08:32 +0000

Add `T: 'static` to `Store` (#10760)* Add `T: 'static` to `StoreSince the beginning the `T` type parameter on `Store` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store` and I've personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I've at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `'static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `'static` bound, and while the number of `unsafe` parts isrelatively small right now we're still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of "lying" has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `'static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it's becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I've additionally [prototyped a change] whichwould additionally practically require `T: 'static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: 'static` on `Store` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: 'static` datawithin a `Store` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `'static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store` to require `'static`here, but the rest of the change is basically "hit compile until rustcsays it's ok". There's not necessarily a huge amount of rhyme-or-reasonto where `'static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can't shyaway from. If problems crop up we'll need to figure out how to threadthat needle at that time, but I'm coming around to thinking that`T: 'static` is just a fundamental constraint we'll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel'sexamples (if they can be fixed, we're not sure of that) we couldconsider relaxing this but that's left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds List of files: /wasmtime-44.0.1/tests/all/async_functions.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/tests/all/async_functions.rs

07c71ab5 - Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions (#10560)

Thu, 10 Apr 2025 15:15:56 +0000

Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions (#10560)* Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functionsRather than forcing all callers to check for `GcHeapOutOfMemory`, trigger a GC,and then try again. This does force us to define `*_async` variations for whenasync is enabled, however; it's ultimately worth it.* cargo fmt* review feedback and fix tests* fix +runtime -gc build* more feedback and build cfg fixes* remove copy-paste assertion that doesn't apply to this method* move assertion into retry methods List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

7a28a5b9 - Remove static/dynamic memories from public docs (#9545)

Tue, 05 Nov 2024 01:05:58 +0000

Remove static/dynamic memories from public docs (#9545)* Remove static/dynamic memories from public docsThis commit removes the terminology of "static" and "dynamic" memoriesfrom the public-facing documentation of Wasmtime, notably on the`Config` structure and its various configuration settings. The goal ofthis commit is in the same vein as #9543 which is to simplify the memorysettings of Wasmtime for users in this case.This change doesn't actually have any code changes beyond renames (andhandling now-deprecated CLI options). The goal of this commit is tobasically rewrite how we document the effect of various settings ofWasmtime. Notably:* `Config::static_memory_maximum_size` is now `memory_reservation`.* `Config::static_memory_forced` is now `memory_reservation_is_maximum`.* `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`.Documentation for all of these options has been rewritten and updated totake into account the removal of "dynamic" and "static" terminology.Additionally more words have been written about the various effects ofeach setting and how things related to wasm features such as index typesizes and custom page sizes.The rewritten documentation is intended to basically already match whatWasmtime does today. I believe that all of these settings are useful inone form or another so none have been dropped but the updateddocumentation is intended to help simplify the mental model for howthey're processed internally and how they affect allocations and such.* Fix how the setting is flipped* Review comments List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

48d5338b - Merge static/dynamic guard size options (#9528)

Fri, 01 Nov 2024 17:21:11 +0000

Merge static/dynamic guard size options (#9528)* Merge static/dynamic guard size optionsThis commit is the first of what will likely be a few to refactor thememory-related configuration options in Wasmtime. The end goal of theserefactorings is to fix some preexisting issues and additionally make theconfiguration easier to understand for both users and implementorsalike. First on the chopping block here is to merge the`dynamic_memory_guard_size` and `static_memory_guard_size` options intoone option. AFAIK there's not a strong reason to have separateconfiguration options for these so it's hopefully simpler to have asingle `memory_guard_size` option which applies to all linear memoriesequally.I'll note that the old CLI options are preserved but are documented asdeprecated. We don't currently warn on using "deprecated options" so fornow the old options are just documented as deprecated and are otherwisesilently accepted.* Fix compilation of C API* Fix build of fuzzers List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

12c20b22 - Implement the Wasm GC instructions for converting between `anyref` and `externref` (#9435)

Thu, 10 Oct 2024 14:41:22 +0000

Implement the Wasm GC instructions for converting between `anyref` and `externref` (#9435)* Implement the Wasm GC instructions for converting between `anyref` and `externref`This commit implements two instructions:1. `any.convert_extern`2. `extern.convert_any`These instructions are used to convert between `anyref` and `externref`values. The `any.convert_extern` instruction takes an `anyref` value andconverts it to an `externref` value. The `extern.convert_any` instruction takesan `externref` value and converts it to an `anyref` value.Rather than implementing wrapper objects -- for example an `structAnyOfExtern(ExternRef)` type that is a subtype of `AnyRef` -- we instead reusethe same representation converted references as their unconverted reference. Forexample, `(any.convert_extern my_externref)` is identical to the original`my_externref` value. This means that we don't actually emit any clifinstructions to implement these Wasm instructions; they are no-ops!Wasm code remains none-the-wiser because it cannot directly test for thedifference between, for example, a `my_anyref` and the result of`(extern.convert_any my_anyref)` because they are in two different typehierarchies, so any direct `ref.test` would be invalid. The Wasm code would haveto convert one into the other's type hierarchy, at which point it doesn't knowwhether wrapping/unwrapping took place.We did need some changes at the host API and host API implementation levels,however:* We needed to relax the requirement that a `wasmtime::AnyRef` only wraps a `VMGcRef` that points to an object that is a subtype of `anyref` and similar for `wasmtime::ExternRef`.* We needed to make the `wasmtime::ExternRef::data[_mut]` methods return an option of their associated host data, since any `externref` resulting from `(extern.convert_any ...)` does not have any associated host data. (This change would have been required either way, even if we used wrapper objects.)* fix tests* fix wasmtime-environ tests List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

05fe6282 - Refactor wasmtime::Func to "unsplat" arguments for the async API (#8732)

Mon, 03 Jun 2024 16:18:58 +0000

Refactor wasmtime::Func to "unsplat" arguments for the async API (#8732)* Complete implementation in wasmtime* Get the impl of IntoFunc to point at the new HostContext from_closure method to tie it back to the new implementation* A little bit of cleanup to comments and naming* Update doc comment for Func wrap_async List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

906ea017 - Use bytes for maximum size of linear memory with pooling (#8628)

Fri, 17 May 2024 04:06:39 +0000

Use bytes for maximum size of linear memory with pooling (#8628)* Use bytes for maximum size of linear memory with poolingThis commit changes configuration of the pooling allocator to use abyte-based unit rather than a page based unit. The previous`PoolingAllocatorConfig::memory_pages` configuration option configuresthe maximum size that a linear memory may grow to at runtime. This is animportant factor in calculation of stripes for MPK and is also acoarse-grained knob apart from `StoreLimiter` to limit memoryconsumption. This configuration option has been renamed to`max_memory_size` and documented that it's in terms of bytes rather thanpages as before.Additionally the documented constraint of `max_memory_size` must besmaller than `static_memory_bound` is now additionally enforced as aminor clean-up as part of this PR as well.* Review comments* Fix benchmark build List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

f3c2a0bb - Fix a panic calling host functions with refs in async mode (#8434)

Mon, 22 Apr 2024 19:25:00 +0000

Fix a panic calling host functions with refs in async mode (#8434)This commit fixes a panic when a host function defined with `Func::new`returned GC references and was called in async mode. The logic toauto-gc before the return values go to wasm asserted that a synchronousGC was possible but the context this function is called in could beeither async or sync. The fix applied in this commit is to remove theauto-gc. This means that hosts will need to explicitly GC in thesesituations until auto-gc is re-added back to Wasmtime.cc #8433 as this will make the behavior consistent, but we'll want tore-add the gc behavior. List of files: /wasmtime-44.0.1/tests/all/async_functions.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/tests/all/async_functions.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/tests/all/async_functions.rs

9ce3ffe1 - Update some CI dependencies (#7983)

Thu, 22 Feb 2024 23:54:03 +0000

Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports List of files: /wasmtime-44.0.1/tests/all/async_functions.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/tests/all/async_functions.rs

2aaeddbd - mpk: restore PKRU state when a fiber resumes execution (#7789)

Thu, 15 Feb 2024 19:31:51 +0000

mpk: restore PKRU state when a fiber resumes execution (#7789)* mpk: restore PKRU state when a fiber resumes executionPreviously, when a fiber was suspended, other computation could changethe PKRU state on the current CPU. This means that the fiber could beresumed with a different PKRU state. This could be bad, resulting insituations in which the fiber can access more memory slots than itshould or cannot even access its own memory slots.This change saves the PKRU state prior to a fiber being suspended. Whenthe fiber resumes execution, that PKRU state is restored.* mpk: check correct PKRU switching on async suspensionThis adds a test that alternately polls two Wasm instances in a loop.Since the instances are async, we can set up epochs to suspend eachfiber as we iterate over a loop. Because we alternate between the twoinstances, it checks that `AsyncCx::block_on` has correctly restored thePKRU bits; otherwise we should see test failures. In the process ofwriting this test I discovered #7942, which can be solved separately(it has to do with the interaction between memory images, _not_ usedhere, and MPK).prtest:full* fix: condition the PKRU context switchesNot all stores have protection keys and MPK is not always enabled. Thischange checks for these conditions before context-switching the PKRUbits. List of files: /wasmtime-44.0.1/tests/all/async_functions.rs

8652011f - Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)

Fri, 09 Feb 2024 21:07:52 +0000

Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)* Refactor `wasmtime::FuncType` to hold a handle to its registered typeRather than holding a copy of the type directly, it now holds a `RegisteredType`which internally is* A `VMSharedTypeIndex` pointing into the engine's types registry.* An `Arc` handle to the engine's type registry.* An `Arc` handle to the actual type.The last exists only to keep it so that accessing a `wasmtime::FuncType`'sparameters and results fast, avoiding any new locking on call hot paths.This is helping set the stage for further types and `TypeRegistry` refactorsneeded for Wasm GC.* Update the C API for the function types refactorprtest:full* rustfmt* Fix benches build List of files: /wasmtime-44.0.1/tests/all/async_functions.rs