Wasmtime GitHub notifications bot (Apr 15 2022 at 19:53): Wasmtime GitHub notifications bot (Apr 15 2022 at 19:53):alexcrichton requested fitzgen for a review on PR #4039.
Wasmtime GitHub notifications bot (Apr 15 2022 at 19:53):alexcrichton opened PR #4039 from component-call-export to main:
This commit is an implementation of the typed method of calling
component exports. This is intended to represent the most efficient way
of calling a component in Wasmtime, similar to whatTypedFunc
represents today for core wasm.Internally this contains all the traits and implementations necessary to
invoke component exports with any type signature (e.g. arbitrary
parameters and/or results). The expectation is that for results we'll
reuse all of this infrastructure except in reverse (arguments and
results will be swapped when defining imports).Some features of this implementation are:
- Arbitrary type hierarchies are supported
The Rust-standard
Option,Result,String,Vec<T>, and tuple
types all map down to the corresponding type in the component model.Basic utf-16 string support is implemented as proof-of-concept to show
what handling might look like. This will need further testing and
benchmarking.Arguments can be behind "smart pointers", so for example
&Rc<Arc<[u8]>>corresponds tolist<u8>in interface types.Bulk copies from linear memory never happen unless explicitly
instructed to do so.The goal of this commit is to create the ability to actually invoke wasm
components. This represents what is expected to be the performance
threshold for these calls where it ideally should be optimal how
WebAssembly is invoked. One major missing piece of this is a#[derive]
of some sort to generate Rust types for arbitrary*.wittypes such as
custom records, variants, flags, unions, etc. The current trait impls
for tuples andResult<T, E>are expected to have fleshed out most of
what such a derive would look like.There are some downsides and missing pieces to this commit and method of
calling components, however, such as:
Passing
&[u8]to WebAssembly is currently not optimal. Ideally this
compiles down to amemcpy-equivalent somewhere but that currently
doesn't happen due to all the bounds checks of copying data into
memory. I have been unsuccessful so far at getting these bounds checks
to be removed.There is no finalization at this time (the "post return" functionality
in the canonical ABI). Implementing this should be relatively
straightforward but at this time requireswasmparserchanges to
catch up with the current canonical ABI.There is no guarantee that results of a wasm function will be
validated. As results are consumed they are validated but this means
that if function returns an invalid string which the host doesn't look
at then no trap will be generated. This is probably not the intended
semantics of hosts in the component model.At this time there's no support for memory64 memories, just a bunch of
FIXMEs to get around to. It's expected that this won't be too
onerous, however. Some extra care will need to ensure that the various
methods related to size/alignment all optimize to the same thing they
do today (e.g. constants).The return value of a typed component function is either
Tor
Value<T>, and it depends on the ABI details ofTand whether it
takes up more than one return value slot or not. This is an
ABI-implementation detail which is being forced through to the API
layer which is pretty unfortunate. For example if you say the return
value of a function is(u8, u32)then it's a runtime type-checking
error. I don't know of a great way to solve this at this time.Overall I'm feeling optimistic about this trajectory of implementing
value lifting/lowering in Wasmtime. While there are a number of
downsides none seem completely insurmountable. There's naturally still a
good deal of work with the component model but this should be a
significant step up towards implementing and testing the component model.
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
Don't we have impls of plain
TforTypedFunc? Can we do the same here? I guess that would introduce ambiguity between a single tuple parameter and N parameters?
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
/// Calling a function which takes multiple parameters and returns a boolean:
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
Maybe easier for folks to understand if we talk about how scalars don't use
Valuevs compound types do useValue? I think they are the same, right? Unless the canonical ABI packs, e.g., an interface type(tuple u32 u32)into a Wasmi64return.
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
Can we factor
0xabout intoconst CANON_ABI_UNINIT_PATTERN: u8 = 0xAB;or something?
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
Debug assert that
alignis a power of two (which the&stuff relies on, I believe)?Alternatively, just use division (which will work with non-powers-of-two) and let LLVM clean up the generated code.
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
Can we
debug_assert!the type signature ofreallochere?
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
other => bail!("expected `string` found `{}`", desc(other)),
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
/// Views this instance of `ComponentParams` as a tuple, allowing
Wasmtime GitHub notifications bot (Apr 18 2022 at 21:15):fitzgen created PR review comment:
// Perform the lowering operation for the parameters which will write
Wasmtime GitHub notifications bot (Apr 19 2022 at 13:59):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Apr 19 2022 at 13:59):alexcrichton created PR review comment:
We do have impls for plain
T, yeah. But yes as you deduced the ambiguity prevents the impl from existing for interface types.
Wasmtime GitHub notifications bot (Apr 28 2022 at 18:49):alexcrichton updated PR #4039 from component-call-export to main.
Wasmtime GitHub notifications bot (May 20 2022 at 20:53):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (May 20 2022 at 20:53):alexcrichton created PR review comment:
Indeed! This is done in
call_raw
Wasmtime GitHub notifications bot (May 20 2022 at 20:54):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (May 20 2022 at 20:54):alexcrichton created PR review comment:
Unfortunately this isn't 100% accurate advice in the sense that
(tuple u32)is returned by-value. No fancy bit-packing happens but if the number of return values is small enough (e.g. 1) then it's returned by-value.
Wasmtime GitHub notifications bot (May 20 2022 at 20:55):alexcrichton updated PR #4039 from component-call-export to main.
Wasmtime GitHub notifications bot (May 24 2022 at 18:08):alexcrichton updated PR #4039 from component-call-export to main.
Wasmtime GitHub notifications bot (May 24 2022 at 18:08):alexcrichton has marked PR #4039 as ready for review.
Wasmtime GitHub notifications bot (May 24 2022 at 18:14):alexcrichton requested fitzgen for a review on PR #4039.
Wasmtime GitHub notifications bot (May 24 2022 at 19:24):alexcrichton updated PR #4039 from component-call-export to main.
Wasmtime GitHub notifications bot (May 24 2022 at 19:26):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (May 24 2022 at 19:26):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (May 24 2022 at 19:26):fitzgen created PR review comment:
// A simple bump allocator which can be used with modules below.
Wasmtime GitHub notifications bot (May 24 2022 at 19:43):alexcrichton updated PR #4039 from component-call-export to main.
Wasmtime GitHub notifications bot (May 24 2022 at 22:02):alexcrichton merged PR #4039.
Last updated: Oct 23 2024 at 20:03 UTC