| d1397130 | 20-Aug-2025 |
Alex Crichton <[email protected]> |
Make const-expr evaluation `async` (#11468)
* Make const-expr evaluation `async`
This commit is extracted from #11430 to accurately reflect how
const-expr evaluation is an async operation due to GC
Make const-expr evaluation `async` (#11468)
* Make const-expr evaluation `async`
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:
* 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
show more ...
|