alexcrichton requested fitzgen for a review on PR #4039.
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*.wit
types 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 requireswasmparser
changes 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
FIXME
s 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
T
or
Value<T>
, and it depends on the ABI details ofT
and 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.
fitzgen submitted PR review.
fitzgen submitted PR review.
fitzgen created PR review comment:
Don't we have impls of plain
T
forTypedFunc
? Can we do the same here? I guess that would introduce ambiguity between a single tuple parameter and N parameters?
fitzgen created PR review comment:
/// Calling a function which takes multiple parameters and returns a boolean:
fitzgen created PR review comment:
Maybe easier for folks to understand if we talk about how scalars don't use
Value
vs 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 Wasmi64
return.
fitzgen created PR review comment:
Can we factor
0xab
out intoconst CANON_ABI_UNINIT_PATTERN: u8 = 0xAB;
or something?
fitzgen created PR review comment:
Debug assert that
align
is 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.
fitzgen created PR review comment:
Can we
debug_assert!
the type signature ofrealloc
here?
fitzgen created PR review comment:
other => bail!("expected `string` found `{}`", desc(other)),
fitzgen created PR review comment:
/// Views this instance of `ComponentParams` as a tuple, allowing
fitzgen created PR review comment:
// Perform the lowering operation for the parameters which will write
alexcrichton submitted PR review.
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.
alexcrichton updated PR #4039 from component-call-export
to main
.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Indeed! This is done in
call_raw
alexcrichton submitted PR review.
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.
alexcrichton updated PR #4039 from component-call-export
to main
.
alexcrichton updated PR #4039 from component-call-export
to main
.
alexcrichton has marked PR #4039 as ready for review.
alexcrichton requested fitzgen for a review on PR #4039.
alexcrichton updated PR #4039 from component-call-export
to main
.
fitzgen submitted PR review.
fitzgen submitted PR review.
fitzgen created PR review comment:
// A simple bump allocator which can be used with modules below.
alexcrichton updated PR #4039 from component-call-export
to main
.
alexcrichton merged PR #4039.
Last updated: Dec 23 2024 at 12:05 UTC