Stream: git-wasmtime

Topic: wasmtime / issue #11617 c-api: component-model: Byte array

Wasmtime GitHub notifications bot (Sep 05 2025 at 13:03):

GerardSmit edited issue #11617:

Currently list<..> is being passed through as WASMTIME_COMPONENT_LIST with wasmtime_component_vallist_t as union type.

In wasmtime_component_vallist_t each item is a wasmtime_component_val. This struct has a size of 32 bytes.

In WASI, list<u8> is used as an byte array, for example in wasi:sockets/udp.
With the implementation in C-API would this need way more memory than needed.

For example, lets say you pass 512 bytes to the component.
Instead of 512 bytes you need to create a wasmtime_component_vallist_t of 512 items, that use 16384 bytes in total.

You also need to transform the bytes to wasmtime_component_val items, which is an additional step you need to do before passing the byte array.

Suggestion

Create a new type, e.g. WASMTIME_COMPONENT_LIST_U8 that uses the union type wasm_byte_vec_t.

Whenever list<u8> is used, the new value type should be used: WASMTIME_COMPONENT_LIST_U8 with wasm_byte_vec_t
For other types, the current type should be used: WASMTIME_COMPONENT_LIST with wasmtime_component_vallist_t

Benefit

Less memory is being passed through C-API, and less overhead (by not transforming the bytes to wasmtime_component_val's)

Implementation

N/A

Alternatives

Accept the fact that every byte is actually 32 bytes when using list<u8>

Or use string instead of list<u8> in WIT, since this uses wasm_byte_vec_t as union type, where the data is a simple byte.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:05):

alexcrichton added the wasmtime:c-api label to Issue #11617.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:05):

alexcrichton added the wasm-proposal:component-model label to Issue #11617.

Wasmtime GitHub notifications bot (Sep 05 2025 at 14:06):

alexcrichton commented on issue #11617:

Yes the current wasmtime_component_val type is meant for feature-complete-ness, not efficiency, and it doesn't really have a path to becoming efficient unfortunately. This is part of https://github.com/bytecodealliance/wasmtime/issues/11501 at a high level in theory, is enabling these sorts of use cases somehow.

Last updated: Dec 06 2025 at 07:03 UTC