Stream: git-wasmtime

Topic: wasmtime / issue #11501 c-api: component-model: An "unche...

Wasmtime GitHub notifications bot (Aug 21 2025 at 23:03):

alexcrichton opened issue #11501:

Currently funciton invocations, both on the host and that of guests, go through wasmtime_component_val_t which is a bit of a heavyweight representation of arguments/results in the component model. Ideally the C API sould support something like wasmtime_func_call_unchecked which places more burden on the caller but is implemented in a much more efficient fashion. Supporting this with the full matrix of types in the component model is unclear how it will be done so this is, to me at least, an open design/research question currently without a solution.

Wasmtime GitHub notifications bot (Aug 21 2025 at 23:03):

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

Wasmtime GitHub notifications bot (Aug 21 2025 at 23:03):

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

Wasmtime GitHub notifications bot (Aug 22 2025 at 11:54):

Digifox03 commented on issue #11501:

As far as calling function whose signature is only known at run time, I don't think there is a better approach that the current one. What I'm interested is improving performance in the case of functions whose signature is known at compile time.

Rather than providing a function like wasmtime_func_call_unchecked, the api can provide a way to get a function pointer. The signature of the function pointer depends on the signature of the component function.

For example, a function like func(a: u32, b: u64) -> s8 can be mapped to a function pointer with type int8_t (*)(uint32_t a, uint64_t b) or with type int8_t (*)(wasmtime_context_t *context, uint32_t a, uint64_t b).

This is also compatible with languages that use systems like libffi to call arbitrary c functions.

Wasmtime GitHub notifications bot (Sep 09 2025 at 17:31):

UserMist commented on issue #11501:

Maybe there could be two api methods, one for setting binary layout for some sort of adapter function generated at a run-time, and the other method for passing raw data matching this layout.
Probably suggesting nonsense though, since I'm new to this project.

Wasmtime GitHub notifications bot (Oct 23 2025 at 15:03):

alexcrichton commented on issue #11501:

Rough idea: the idea above I think would make sense but I'd prefer to avoid dealing with things like libffi to dynamically invoke functions of different type signatures. Instead I'd perfer to invoke functions of a single type signature. The question then is what signature is faster than today but still works for all functions?

The rough idea is that the signature is wasmtime_error_t *(*)(void*, wasmtime_context_t*, void *args_and_results, size_t args_and_results_len) where args/results are "serialized" into an area. This serialization would be somewhat lightweight, for example integers would just push themselves, records would push fields, etc. More-or-less this would be the canonical ABI in-memory format anyway (unsure what to do about alignment). The tricky parts are:

• Resources - these wouldn't look like the canonical ABI. Probably would look like wasmtime_component_resource_any_t* or something like that.
• Strings - I'm imagining that coming from the guest it'd be a raw pointer into linear memory (pre-validated) or host memory (if not utf-8). The thinking is that a post-return operation would be required to be deferred until after arguments were read. Going into the guest I'm thinking these would be raw pointers into host memory. Cleanup... TBD.
• Lists - This is the roughest idea part. Instead of raw pointers lists would be a sort of "tombstone" where you'd go back to some sort of Wasmtime context and say "hey give me the contents of the list". This would prevent Wasmtime from allocating anything and the embedder would be the one providing any sort of memory buffers.

Not enough to implement things, but wanted to at least write down what I thought were the trickiest bits (resources/strings/lists)

Last updated: Dec 06 2025 at 06:05 UTC