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

* Refactor component model host function definitions

Push the `async`-ness down one layer.

* Remove need for explicit `Config::async

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

* Refactor component model host function definitions

Push the `async`-ness down one layer.

* Remove need for explicit `Config::async_support` knob

This commit is an attempt to step towards reconciling "old async" and
"new async" in Wasmtime. The old async style is the original async
support in Wasmtime with `call_async`, `func_wrap_async`, etc, where the
main property is that the store is "locked" during an async operation.
Put another way, a store can only execute at most one async operation at
a time. This is in contrast to "new async" support in Wasmtime with the
component-model-async (WASIp3) support, where stores can have more than
one async operation in flight at once.

This commit does not fully reconcile these differences, but it does
remove one hurdle along the way: `Config::async_support`. Since the
beginning of Wasmtime this configuration knob has existed to explicitly
demarcate a config/engine/store as "this thing requires `async` stuff
internally." This has started to make less and less sense over time
where the line between sync and async has become more murky with WASIp3
where 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 many
load-bearing aspects of Wasmtime that rely on this `async_support` knob.
For example once epochs + yielding are enabled it's required that all
Wasm is executed on a fiber lest it hit an epoch and not know how to
yield. That means that this commit is not a simple removal of
`async_support` but instead a refactoring/rearchitecting of how async is
used internally within Wasmtime. The high-level ideas within Wasmtime
now 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 now
gone. All stores are equally capable of executing sync/async, and the
change now is that dynamically some stores will require that async is
used with certain configuration. Additionally all panicking conditions
around `async_support` have been converted to errors instead. All
relevant APIs already returned an error and things are murky enough now
that it's not necessarily trivial to get this right at the embedder
level. In the interest of avoiding panics all detected async mismatches
are now first-class `wasmtime::Error` values.

The end result of this commit is that `Config::async_support` is a
deprecated `#[doc(hidden)]` function that does nothing. While many
internal changes happened as well as having new tests for all this sort
of behavior this is not expected to have a great impact on external
consumers. In general a deletion of `async_support(true)` is in theory
all that's required. This is intended to make it easier to think about
async/sync/etc in the future with WASIp3 and eventually reconcile
`func_wrap_async` and `func_wrap_concurrent` for example. That's left
for future refactorings however.

prtest:full

* Review comments

* Fix CI failures

show more ...

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

Now possible after #10785

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

* Wasmtime: generalize `async_stack_zeroing` knob to cover initialization

This commit moves the knob from the `Pooli

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

* Wasmtime: generalize `async_stack_zeroing` knob to cover initialization

This commit moves the knob from the `PoolingInstanceAllocatorConfig` to the
regular `Config` and now controls both whether stacks are zeroed before reuse
and whether they are zeroed before the initial use. The latter doesn't matter
usually, since anonymous mmaps are already zeroed so we don't have to do
anything there, but for no-std environments it is the difference between
manually zeroing the stack or simply using unininitialized memory.

* Fix CLI and test builds

* fix default config value

* fix some more tests

show more ...

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

* Enable `unsafe-attr-outside-unsafe` 2024 edition lint

This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used
in tran

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

* Enable `unsafe-attr-outside-unsafe` 2024 edition lint

This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used
in 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 here
are a simple search/replace.

* Another attribute update

* Fix command adapter build

show more ...

Print an error on async stack overflow (#9304)

* Print an error on async stack overflow

This commit updates Wasmtime's handling of traps on Unix platforms to
print an error message on stack overflo

Print an error on async stack overflow (#9304)

* Print an error on async stack overflow

This commit updates Wasmtime's handling of traps on Unix platforms to
print an error message on stack overflow when the guard page is hit.
This is distinct from stack overflow in WebAssembly which raises a
normal trap and can be caught. This is instead to be used on
misconfigured hosts where the async stack is too small or wasm was
allowed to take up too much of the async stack. Currently no error
message is printed and the program simply aborts with a core dump which
can be difficult to debug.

This instead registers the range of the async guard page with the trap
handling infrastructure to test the faulting address and if it lies
within this range. If so then a small message is printed and then the
program is aborted with `libc::abort()`.

This does not impact the safety of any prior embedding or fix any
issues. It's instead intended purely as a diagnostic tool to help users
more quickly understand that stack size configuration settings are the
likely culprit.

* Fix build of c-api and tests

prtest:full

* Fix build on Windows

* Fix a warning on Windows

* Fix dead code on miri

show more ...

Reduce typo count (#9106)

Enforce `clippy::clone_on_copy` for the workspace (#9025)

* Derive `Copy` for `Val`

* Fix `clippy::clone_on_copy` for the whole repo

* Enforce `clippy::clone_on_copy` for the workspace

* fix some

Enforce `clippy::clone_on_copy` for the workspace (#9025)

* Derive `Copy` for `Val`

* Fix `clippy::clone_on_copy` for the whole repo

* Enforce `clippy::clone_on_copy` for the workspace

* fix some more clippy::clone_on_copy that got missed

show more ...

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

* c-api: Create `RootScope` where necessary

This commit changes the `wasmtime_val_t::{from_val, to_val}` methods to
take a `RootScope` instead of a

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

* c-api: Create `RootScope` where necessary

This commit changes the `wasmtime_val_t::{from_val, to_val}` methods to
take a `RootScope` instead of any `AsContextMut`. This then required a
number of refactorings in callers to ensure that a `RootScope` was
created for any function that needed one. This is required to ensure
that GC references in the C API aren't forced to live for the entire
lifetime of the store.

This additionally added `*_unrooted` variants which do the same thing
but don't require `RootScope`. This was needed for when the C API calls
out to the embedder through a function call because a new `RootScope`
wouldn't work for return values (they're bound to a scope within the
closure when we want them to outlive the closure). In these situations
though we know a `RootScope` is already present at the entrypoint.

Closes #8367

* Review comments

show more ...

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 distinguish
between `wasm.h` APIs and `wasmtime.h` API

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 distinguish
between `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-related
types. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is related
to `wasmtime.h`.

* `StoreRef` -> `WasmStoreRef`
* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases
* `StoreData` -> `WasmtimeStoreData`
* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`
* Introduce the `Wasmtime{Store,Caller}` aliases

show more ...

Define garbage collection rooting APIs (#8011)

* Define garbage collection rooting APIs

Rooting prevents GC objects from being collected while they are actively being
used.

We have a few sometimes

Define garbage collection rooting APIs (#8011)

* Define garbage collection rooting APIs

Rooting prevents GC objects from being collected while they are actively being
used.

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 to
support (2). Ideally, for ergonomics, a root would automatically unroot itself
when dropped. But in the general case that requires holding a reference to the
store's root set, and that root set needs to be held simultaneously by all GC
roots, and they each need to mutate the set to unroot themselves. That implies
`Rc<RefCell<...>>` or `Arc<Mutex<...>>`! The former makes the store and GC root
types not `Send` and not `Sync`. The latter imposes synchronization and locking
overhead. So we instead make GC roots indirect and require passing in a store
context explicitly to unroot in the general case. This trades worse ergonomics
for better performance and support for moving GC and async Rust.

Okay, with that out of the way, this module provides two flavors of rooting
API. One for the common, scoped lifetime case, and another for the rare case
where we really need a GC root with an arbitrary, non-LIFO/non-scoped lifetime:

1. `RootScope` and `Rooted<T>`: 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<T>`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<T>` 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<T>` at a time, since the `Rooted<T>` would take a borrow
of the whole context.

This supports the common use case for rooting and provides good ergonomics.

2. `ManuallyRooted<T>`: 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<T>` 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<T>`],
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<T>`]: http://devdoc.net/web/developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS::PersistentRooted.html

At the end of the day, both `Rooted<T>` and `ManuallyRooted<T>` are just tagged
indices into the store's `RootSet`. This indirection allows working with Rust's
borrowing discipline (we use `&mut Store` to represent mutable access to the GC
heap) while still allowing rooted references to be moved around without tying up
the whole store in borrows. Additionally, and crucially, this indirection allows
us 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<StoreContext[Mut]<'a, T>` 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 correct

Remove 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 API

Until we can add proper GC rooting.

* Remove doxygen reference to temp deleted function

* Remove need to `allow(private_interfaces)`

* Fix call benchmark compilation

show more ...

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

* Refactor `wasmtime::FuncType` to hold a handle to its registered type

Rather than holding a copy of the type directly

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

* Refactor `wasmtime::FuncType` to hold a handle to its registered type

Rather 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`'s
parameters and results fast, avoiding any new locking on call hot paths.

This is helping set the stage for further types and `TypeRegistry` refactors
needed for Wasm GC.

* Update the C API for the function types refactor

prtest:full

* rustfmt

* Fix benches build

show more ...

c-api: support yielding in wasmtime_store_epoch_deadline_callback (#7476)

* c-api: reuse CallbackDataPtr

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: support yielding in epoch de

c-api: support yielding in wasmtime_store_epoch_deadline_callback (#7476)

* c-api: reuse CallbackDataPtr

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: support yielding in epoch deadline callback

Signed-off-by: Tyler Rockwood <[email protected]>

* Use triple slash doc comments

prtest:full

* c-api: guard yield behind async cfg flag

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: prevent dead code warnings with no default features

Signed-off-by: Tyler Rockwood <[email protected]>

---------

Signed-off-by: Tyler Rockwood <[email protected]>

show more ...

Switch to simpler fuel APIs (#7298)

In an effort to simplify the many fuel related APIs, simplify the
interface here to a single counter with get and set methods.
Additionally the async yield is red

Switch to simpler fuel APIs (#7298)

In an effort to simplify the many fuel related APIs, simplify the
interface here to a single counter with get and set methods.
Additionally the async yield is reduced to an interval of the total fuel
instead of injecting fuel, so it's easy to still reason about how much
fuel is left even with yielding turned on.

Internally this works by keeping two counters - one the VM uses to
increment towards 0 for fuel, the other to track how much is in
"reserve". Then when we're out of gas, we pull from the reserve to
refuel and continue. We use the reserve in two cases: one for overflow
of the fuel (which is an i64 and the API expresses fuel as u64) and the
other for async yieling, which then the yield interval acts as a cap to
how much we can refuel with.

This also means that `get_fuel` can return the full range of `u64`
before this change it could only return up to `i64::MAX`. This is
important because this PR is removing the functionality to track fuel
consumption, and this makes the API less error prone for embedders to
track consumption themselves.

Careful to note that the VM counter that is stored as `i64` can be
positive if an instruction "costs" multiple units of fuel when the fuel
ran out.

prtest:full

Signed-off-by: Tyler Rockwood <[email protected]>

show more ...

Introduce API for custom stack memory (#7209)

* Introduce StackMemory and StackMemoryCreator

This allows custom implementations of stack memory to be plugged into
the async functionality for wasmti

Introduce API for custom stack memory (#7209)

* Introduce StackMemory and StackMemoryCreator

This allows custom implementations of stack memory to be plugged into
the async functionality for wasmtime. Currently, stacks are always
mmapped, and this custom allocator allows embedders to use any memory
they would like.

The new APIs are also exposed in the C api.

This has no effect on windows, as our hands are tied with fibers there.

Signed-off-by: Tyler Rockwood <[email protected]>

* Add test for custom host memory

Signed-off-by: Tyler Rockwood <[email protected]>

* fix allocator test

Signed-off-by: Tyler Rockwood <[email protected]>

* Address review comments

Signed-off-by: Tyler Rockwood <[email protected]>

* Fix lint warnings

prtest:full

Signed-off-by: Tyler Rockwood <[email protected]>

* fix windows lint warning

prtest:full

Signed-off-by: Tyler Rockwood <[email protected]>

---------

Signed-off-by: Tyler Rockwood <[email protected]>

show more ...

c-api: Support InstancePre (#7140)

* c-api: Support InstancePre

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Consolidate all the instance_pre functionality

Signed-off-by: Tyler

c-api: Support InstancePre (#7140)

* c-api: Support InstancePre

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Consolidate all the instance_pre functionality

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Add async instantiate support to pre instances

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Add star to comment for doxygen

prtest:full

Signed-off-by: Tyler Rockwood <[email protected]>

---------

Signed-off-by: Tyler Rockwood <[email protected]>

show more ...

Async support in the C API (#7106)

* c-api: Add a feature for async

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Add support for async config

Signed-off-by: Tyler Rockwood <rock

Async support in the C API (#7106)

* c-api: Add a feature for async

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Add support for async config

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Add support for calling async functions

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Add ability to yield execution of Wasm in a store

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Introduce wasmtime_linker_instantiate_async

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Support defining async host functions

Signed-off-by: Tyler Rockwood <[email protected]>

* gitignore: ignore cmake cache for examples

Signed-off-by: Tyler Rockwood <[email protected]>

* examples: Add example of async API in C

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Consolidate async functionality into a single place

Put all the async stuff in it's own header and own rust source file

Also remove the wasmtime_async_continuation_new function, users can just
allocate it directly.

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Make async function safe

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Remove wasmtime_call_future_get_results

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Simplify CHostCallFuture

Move the result translation and hostcall_val_storage usage into an async
function

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Simplify C continuation implementation

Remove the caller, which means that we don't need another struct for the
future implementation.

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Improve async.h documentation

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Cleanup from previous changes

Signed-off-by: Tyler Rockwood <[email protected]>

* examples: Fix example

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Simplify continuation callback

This gives more duality with calling an async function and also means
that the implementation can pretty much mirror the sync version.

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Fix async.h documentation

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Fix documentation for async.h

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: Review feedback

Signed-off-by: Tyler Rockwood <[email protected]>

* examples: Downgrade async.cpp example to C++11

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: initialize continuation with a panic callback

Signed-off-by: Tyler Rockwood <[email protected]>

* prtest:full

Signed-off-by: Tyler Rockwood <[email protected]>

---------

Signed-off-by: Tyler Rockwood <[email protected]>

show more ...