Stream: git-wasmtime

Topic: wasmtime / issue #4310 Implement calling a "dynamically t...

Wasmtime GitHub notifications bot (Jun 23 2022 at 21:51):

alexcrichton opened issue #4310:

For core wasm Wasmtime offers the Func and TypedFunc APIs for calling into WebAssembly. The current intention is to provide the same for the component model. Currently the TypedFunc API exists, but the Func API doesn't actually support calls.

The intended use case for this feature is for something like the wasmtime CLI where it wants to be able to call any component it loads so we can't statically enumerate the signatures ahead of time. It's expected that this version of calling a component is slower (perhaps significantly so) than calling a typed function.

Currently I don't have many ideas about how the implementation will be done. The rough idea is that there'd be some sort of wasmtime::Val equivalent but for the component model. Like with Val the actual value iteslf is "tagged" with the type information. The actual implementation of this is going to be much trickier than core wasm because Val only deals with primitives and a component model value can recursively contain other component model values. This will likely imply a significant overhead in terms of allocations, indirection, and management.

I do not think that the wasmtime::component::Val type will implement any of ComponentValue, Lift, or Lower. Those are intended only for types where the type in the component model is statically known at compile-time.

This work is also motivated by unlocking half of the fuzzing possiblities in https://github.com/bytecodealliance/wasmtime/issues/4307

Wasmtime GitHub notifications bot (Jun 23 2022 at 21:51):

alexcrichton labeled issue #4310:

For core wasm Wasmtime offers the Func and TypedFunc APIs for calling into WebAssembly. The current intention is to provide the same for the component model. Currently the TypedFunc API exists, but the Func API doesn't actually support calls.

The intended use case for this feature is for something like the wasmtime CLI where it wants to be able to call any component it loads so we can't statically enumerate the signatures ahead of time. It's expected that this version of calling a component is slower (perhaps significantly so) than calling a typed function.

Currently I don't have many ideas about how the implementation will be done. The rough idea is that there'd be some sort of wasmtime::Val equivalent but for the component model. Like with Val the actual value iteslf is "tagged" with the type information. The actual implementation of this is going to be much trickier than core wasm because Val only deals with primitives and a component model value can recursively contain other component model values. This will likely imply a significant overhead in terms of allocations, indirection, and management.

I do not think that the wasmtime::component::Val type will implement any of ComponentValue, Lift, or Lower. Those are intended only for types where the type in the component model is statically known at compile-time.

This work is also motivated by unlocking half of the fuzzing possiblities in https://github.com/bytecodealliance/wasmtime/issues/4307

Wasmtime GitHub notifications bot (Jun 23 2022 at 21:53):

alexcrichton commented on issue #4310:

One other thing worth mentioning here is that the support here not only applies to wasmtime::component::Func but also the wasmtime::component::Linker type. Ideally a host function can be defined generically with a runtime-defined signature which allows other interesting forms of fuzzing and such. My hope would be that if untyped values work in Func it would be relatively easy to add support to Linker to do the same thing.

Wasmtime GitHub notifications bot (Jul 08 2022 at 14:15):

dicej commented on issue #4310:

I'm going to start experimenting with this today.

Wasmtime GitHub notifications bot (Jul 13 2022 at 14:37):

dicej commented on issue #4310:

Quick update: I've mostly finished with this -- just fleshing out the test suite. Should have a PR up today.

Wasmtime GitHub notifications bot (Jul 25 2022 at 18:39):

alexcrichton commented on issue #4310:

Implemented in https://github.com/bytecodealliance/wasmtime/pull/4442

Wasmtime GitHub notifications bot (Jul 25 2022 at 18:39):

alexcrichton closed issue #4310:

For core wasm Wasmtime offers the Func and TypedFunc APIs for calling into WebAssembly. The current intention is to provide the same for the component model. Currently the TypedFunc API exists, but the Func API doesn't actually support calls.

The intended use case for this feature is for something like the wasmtime CLI where it wants to be able to call any component it loads so we can't statically enumerate the signatures ahead of time. It's expected that this version of calling a component is slower (perhaps significantly so) than calling a typed function.

Currently I don't have many ideas about how the implementation will be done. The rough idea is that there'd be some sort of wasmtime::Val equivalent but for the component model. Like with Val the actual value iteslf is "tagged" with the type information. The actual implementation of this is going to be much trickier than core wasm because Val only deals with primitives and a component model value can recursively contain other component model values. This will likely imply a significant overhead in terms of allocations, indirection, and management.

I do not think that the wasmtime::component::Val type will implement any of ComponentValue, Lift, or Lower. Those are intended only for types where the type in the component model is statically known at compile-time.

This work is also motivated by unlocking half of the fuzzing possiblities in https://github.com/bytecodealliance/wasmtime/issues/4307

Last updated: Oct 23 2024 at 20:03 UTC