Implement support for async functions in Wasmtime
#2434
Merged
Conversation
This file contains 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
cfallin
reviewed
Nov 19, 2020
github-actions
bot
added
the
wasmtime:api
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Jan 21, 2021
Instantiation right now uses a recursive `instantiate` function since it was relatively easy to write that way, but this is unfortunately not factored in a way friendly to the async implementation in bytecodealliance#2434. This commit refactors the function to instead use an iterative loop and refactors code in such a way that it should be easy to rebase bytecodealliance#2434 on top of this change. The main goal is to make the body of `Instance::new` as small as possible since it needs to be duplicated with `Instance::new_async`.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Jan 21, 2021
Instantiation right now uses a recursive `instantiate` function since it was relatively easy to write that way, but this is unfortunately not factored in a way friendly to the async implementation in bytecodealliance#2434. This commit refactors the function to instead use an iterative loop and refactors code in such a way that it should be easy to rebase bytecodealliance#2434 on top of this change. The main goal is to make the body of `Instance::new` as small as possible since it needs to be duplicated with `Instance::new_async`.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Jan 21, 2021
Instantiation right now uses a recursive `instantiate` function since it was relatively easy to write that way, but this is unfortunately not factored in a way friendly to the async implementation in bytecodealliance#2434. This commit refactors the function to instead use an iterative loop and refactors code in such a way that it should be easy to rebase bytecodealliance#2434 on top of this change. The main goal is to make the body of `Instance::new` as small as possible since it needs to be duplicated with `Instance::new_async`.
alexcrichton
added a commit
that referenced
this pull request
Jan 21, 2021
Instantiation right now uses a recursive `instantiate` function since it was relatively easy to write that way, but this is unfortunately not factored in a way friendly to the async implementation in #2434. This commit refactors the function to instead use an iterative loop and refactors code in such a way that it should be easy to rebase #2434 on top of this change. The main goal is to make the body of `Instance::new` as small as possible since it needs to be duplicated with `Instance::new_async`.
smacleod
reviewed
Jan 26, 2021
alexcrichton
force-pushed
the
async
branch
4 times, most recently
from
1e398ca
to
2742bcd
Compare
3 tasks
peterhuene
reviewed
Feb 4, 2021
alexcrichton
force-pushed
the
async
branch
2 times, most recently
from
d268d6c
to
2ecaf08
Compare
peterhuene
reviewed
Feb 5, 2021
This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: bytecodealliance/rfcs#2
This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures.
Turns out this is another caller-saved register!
Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses.
With fuel it's probably best to not provide any way to inject infinite fuel.
* Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM
peterhuene
reviewed
Feb 26, 2021
| .flat_map(|f| f.symbols()) | ||
| .filter_map(|s| Some(s.name()?.to_string())) | ||
| .any(|s| s.contains("look_for_me")) | ||
| // TODO: apparently windows unwind routines don't unwind through fibers, so this will always fail. Is there a way we can fix that? |
There was a problem hiding this comment.
I'll ping some Microsoft debugger folks to see if it's a known limitation of StackWalkEx when the given thread is a fiber. I suspect RtlVirtualUnwind might not have this problem.
peterhuene
reviewed
Feb 26, 2021
peterhuene
reviewed
Feb 26, 2021
peterhuene
approved these changes
Feb 26, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 is an implementation of RFC 2 in Wasmtime which is to support
async-defined host functions. At a high level support is added byexecuting WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.
There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:
A new
wasmtime-fibercrate has been written to manage the low-leveldetails of stack-switching. Unixes use
mmapto allocate a stack andWindows uses the native fibers implementation. We'll surely want to
refactor this to move stack allocation elsewhere in the future. Fibers
are intended to be relatively general with a lot of type paremters to
fling values back and forth across suspension points. The whole crate
is a giant wad of
unsafeunfortunately and involves handwrittenassembly with custom dwarf CFI directives to boot. Definitely deserves
a close eye in review!
The
Storetype has two new methods --block_onandon_fiberwhich bridge between the async and non-async worlds. Lots of unsafe
fiddly bits here as we're trying to communicate context pointers
between disparate portions of the code. Extra eyes and care in review
is greatly appreciated.
The APIs for binding
asyncfunctions are unfortunately pretty uglyin
Func. This is mostly due to language limitations and compilerbugs (I believe) in Rust. Instead of
Func::wrapwe have aFunc::wrapN_asyncfamily of methods, and we've also got a wholebunch of
Func::getN_asyncmethods now too. It may be worthrethinking the API of
Functo try to make the documentation pageactually grok'able.
This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!