This repository was archived by the owner on Sep 8, 2025. It is now read-only.
Merge with upstream#234
Merged
Merged
Conversation
I noticed that `cargo build -p wasmtime-cli` was enabling the `component-model-async` feature in `wasmtime` by default, despite that feature being off by default for `wasmtime-cli`. I traced it down to the `wast` crate, which was enabling `wasmtime/component-model-async` whenever the `component-model` feature was enabled. This commit separates them into distinct features. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
* Remove `Table::from_wasmtime_table` This commit removes the unsafe function `Table::from_wasmtime_table`. This goes a bit further and removes `ExportTable` entirely as well which means that table lookup on a `vm::Instance` directly returns a `wasmtime::Table` without any need to translate back-and-forth. * Remove `Tag::from_wasmtime_tag` Like the previous commit, but for tags. * Remove `Global::from_wasmtime_global` Like the previous commit, but for globals. * Remove `Memory::from_wasmtime_memory` Like the previous commit, but for memories. * Remove `Func::from_wasmtime_function` Like previous commits, but for functions. * Fix lints * Fill out missing safety comment * Review comments
* Start to use `&Accessor<T, D>` more in concurrent code
After discussion with Joel we've concluded that while `&mut Accessor<T, D>`
was originally added to model host functions it is also appropriate to
use it to model embedder-rooted invocations of items such as wasm as
well. Effectively the conclusion we reached was that
`*::call_concurrent` should be taking `&Accessor`, not
`StoreContextMut`. This has a number of benefits to it over the previous
iteration:
* This makes exports behave more like imports where `Accessor` means
"you're in the concurrent world".
* This makes exports have an `async fn` signature which is easier to
read and understand.
* This automatically enforces the guarantee that the returned future is
only polled within the main event loop because the future is always
considered to close over the `&Accessor` provided meaning it
statically cannot live outside of the event loop.
* This paves the way forward to future refactorings to avoid storing so
much state within a `Store<T>` and instead try to store state directly
in futures themselves. This should make cancellation more natural and
eventually also remove `'static` bounds on params/results. Furthermore
this should make it easier to avoid spawning tasks internally by
storing state in futures instead of spawned tasks.
In doing this one of the main questions we were faced with was what to
do about `&mut Accessor<T, D>`, namely the `mut` part. With a mutable
accessor it would be only possible to call one function concurrently.
One option considered was to add combinators like `Accessor::join` and
`Accessor::race` but in the end we decided to avoid going that direction
and instead switch to `&Accessor<T, D>` everywhere, freely enabling
aliasing of the accessor. This has the downside that `Accessor::with` is
now a relatively dangerous function in that it can panic, but idiomatic
usage of it is not expected to panic as the distinction between the
`async` and sync boundary of `Accessor` vs `StoreContextMut` is expected
to naturally make the recursive panic condition of `with` rare to come
up in practice.
Concrete changes in this commit are:
* `Accessor::with` now requires `&self`.
* `Accessor::spawn` now requires `&self`.
* Host functions are now given `&Accessor`, not `&mut Accessor`.
* `{Typed,}Func::call_concurrent` is now an `async fn` which takes an
`&Accessor` instead of `StoreContextMut`.
* Guest bindings generation for concurrent invocations now looks exactly
like async bindings generation except for replacing `StoreContextMut`
with `Accessor`.
Note that this commit does not yet update the internal implementations
of these functions to benefit from the new abilities that taking
`&Accessor` implies. Instead that's deferred to a future update as
necessary. Instead this is only updating the public API of the
`wasmtime` crate to enable these refactorings in the future.
Also note that this does not yet update all functions to take
`&Accessor`. Notably futures and streams still need to be updated.
cc #11224
* Review comments
---------
Co-authored-by: Joel Dice <joel.dice@fermyon.com>
* 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.
This commit fixes an accidental regression from #11097 where a `select_spectre_guard` with a boolean condition that and'd two CCs together would fail to lower and cause a panic during lowering. This was reachable when explicit bounds checks are enabled from wasm, for example. The fix here is to handle the `And` condition in the same way that lowering `select` does which is to model that as it flows into the select helper.
* fix(wasmtime): fix `--no-default-features` with async
Currently, building `wasmtime` via:
```
$ cargo build -p wasmtime --no-default-features --features component-model-async
```
fails with:
```
error[E0432]: unresolved import `wasmtime_environ::fact`
--> crates/wasmtime/src/runtime/component/concurrent.rs:88:36
|
88 | use wasmtime_environ::{PrimaryMap, fact};
| ^^^^ no `fact` in the root
|
note: found an item that was configured out
--> /Users/rvolosatovs/src/github.com/bytecodealliance/wasmtime/crates/environ/src/lib.rs:72:9
|
72 | pub mod fact;
| ^^^^
note: the item is gated here
--> /Users/rvolosatovs/src/github.com/bytecodealliance/wasmtime/crates/environ/src/lib.rs:71:1
|
71 | #[cfg(all(feature = "component-model", feature = "compile"))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
in order to avoid the need for `component-model-async` feature to enable
`wasmtime-environ/compile`, promote `START_FLAG_ASYNC_CALLEE` to
crate-level const
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* ci: test `component-model-async` with no default features
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* refactor: move async const to `component`
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
---------
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
* Implement Tarjan's strongly-connected components algorithm This commit implements [Tarjan's algorithm] for finding strongly-connected components. This algorithm takes `O(V+E)` time and uses `O(V+E)` space. Tarjan's algorithm is usually presented as a recursive algorithm, but we do not trust the input and cannot recurse over it for fear of blowing the stack. Therefore, this implementation is iterative. This will be used to do bottom-up inlining in Wasmtime's compilation orchestration. [Tarjan's algorithm]: https://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm * address review feedback
* Make direct calls to statically-known imported functions This will allow for their eventual inlining. * address review feedback and fix up some disas tests * Add native code disassembly test * disas: sort `read_dir` entries for deterministic order Because we always use namespace 0 for wasm functions when creating CLIF functions, sorting the parsed CLIF functions by (namespace, index) does not differentiate between the `index`th Wasm function in two different modules in the same component, meaning we would pass through whatever ordering reading from the filesystem gave us, which can be non-deterministic across platforms. Instead, sort the directory entries based on file paths. * fix clippy
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 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.
No description provided.