Make const-expr evaluation async
#11468
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit is extracted from bytecodealliance#11430 to accurately reflect how const-expr evaluation is an async operation due to GC pauses that may happen. The changes in this commit are: * Const-expr evaluation is, at its core, now an `async` function. * To leverage this new `async`-ness all internal operations are switched from `*_maybe_async` to `*_async` meaning all the `*_maybe_async` methods can be removed. * Some libcalls using `*_maybe_async` are switch to using `*_async` plus the `block_on!` utility to help jettison more `*_maybe_async` methods. * Instance initialization is now an `async` function. This is temporarily handled with `block_on` during instance initialization to avoid propagating the `async`-ness further upwards. This `block_on` will get deleted in future refactorings. * Const-expr evaluation has been refactored slightly to enable having a fast path in global initialization which skips an `await` point entirely, achieving performance-parity in benchmarks prior to this commit. This ended up fixing a niche issue with GC where if a wasm execution was suspended during `table.init`, for example, during a const-expr evaluation triggering a GC then if the wasm execution was cancelled it would panic the host. This panic was because the GC operation returned `Result` but it was `unwrap`'d as part of the const-expr evaluation which can fail not only to invalid-ness but also due to "computation is cancelled" traps.
Member
Author
|
Actually, thinking more, the issue about panicking on const expr evaluation failure means allocation failure in GC is a host panic which isn't great. Deferring that to a separate issue. |
This was referenced Aug 19, 2025
github-actions
bot
added
wasmtime:api
Subscribe to Label Actioncc @fitzgen
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
fitzgen
approved these changes
Aug 20, 2025
| }; | ||
| block_on!(store, async |store| { | ||
| let gc_ref = store | ||
| .retry_after_gc_async((), |store, ()| { |
Member
There was a problem hiding this comment.
Are there any non-async retry_after_gc calls at this point? I think all of them should be async by the time we finish the asyncification of the internals, but I'm not sure if we are there yet or not. But when we are, we should delete the non-async version and then just rename the async variation to plain retry_after_gc.
Member
Author
There was a problem hiding this comment.
Soon! (got a PR queued up after #11470 to delete the sync version
Comment on lines
+380
to
+397
| if store.async_support() { | ||
| #[cfg(feature = "async")] | ||
| store.block_on(|store| { | ||
| let module = compiled_module.module().clone(); | ||
| Box::pin( | ||
| async move { vm::initialize_instance(store, id, &module, bulk_memory).await }, | ||
| ) | ||
| })??; | ||
| #[cfg(not(feature = "async"))] | ||
| unreachable!(); | ||
| } else { | ||
| vm::assert_ready(vm::initialize_instance( | ||
| store, | ||
| id, | ||
| compiled_module.module(), | ||
| bulk_memory, | ||
| ))?; | ||
| } |
Member
There was a problem hiding this comment.
And then Instance::new_raw will become an async function in another follow up PR?
bongjunj
pushed a commit
to prosyslab/wasmtime
that referenced
this pull request
Oct 20, 2025
* Make const-expr evaluation `async` This commit is extracted from bytecodealliance#11430 to accurately reflect how const-expr evaluation is an async operation due to GC pauses that may happen. The changes in this commit are: * Const-expr evaluation is, at its core, now an `async` function. * To leverage this new `async`-ness all internal operations are switched from `*_maybe_async` to `*_async` meaning all the `*_maybe_async` methods can be removed. * Some libcalls using `*_maybe_async` are switch to using `*_async` plus the `block_on!` utility to help jettison more `*_maybe_async` methods. * Instance initialization is now an `async` function. This is temporarily handled with `block_on` during instance initialization to avoid propagating the `async`-ness further upwards. This `block_on` will get deleted in future refactorings. * Const-expr evaluation has been refactored slightly to enable having a fast path in global initialization which skips an `await` point entirely, achieving performance-parity in benchmarks prior to this commit. This ended up fixing a niche issue with GC where if a wasm execution was suspended during `table.init`, for example, during a const-expr evaluation triggering a GC then if the wasm execution was cancelled it would panic the host. This panic was because the GC operation returned `Result` but it was `unwrap`'d as part of the const-expr evaluation which can fail not only to invalid-ness but also due to "computation is cancelled" traps. * Fix configured build * Undo rebase mistake
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit is extracted from #11430 to accurately reflect how const-expr evaluation is an async operation due to GC pauses that may happen. The changes in this commit are:
asyncfunction.async-ness all internal operations are switched from*_maybe_asyncto*_asyncmeaning all the*_maybe_asyncmethods can be removed.*_maybe_asyncare switch to using*_asyncplus theblock_on!utility to help jettison more*_maybe_asyncmethods.asyncfunction. This is temporarily handled withblock_onduring instance initialization to avoid propagating theasync-ness further upwards. Thisblock_onwill get deleted in future refactorings.awaitpoint entirely, achieving performance-parity in benchmarks prior to this commit.This ended up fixing a niche issue with GC where if a wasm execution was suspended during
table.init, for example, during a const-expr evaluation triggering a GC then if the wasm execution was cancelled it would panic the host. This panic was because the GC operation returnedResultbut it wasunwrap'd as part of the const-expr evaluation which can fail not only to invalid-ness but also due to "computation is cancelled" traps.