Wasm GC and Preview 2 · wasmtime

I understand that one is a WASM standard and the other is a Wasi standard but I was curious about the interaction. Is there anything that stops these 2 standard from coexisting? E.g items going through the GC standard can use the appropriate grow methods and wasi p2 bindings can stick to realloc

Lann Martin (May 21 2025 at 19:28):

The component model is an extension of core wasm and I believe the goal is for it to be a wasm standard in the future. GC support is on the roadmap for the component model but not until after the next release (0.3). You might be interested in this: YouTube - - YouTube

Cwasi4wasm (May 21 2025 at 19:35):

Lann Martin said:

The component model is an extension of core wasm and I believe the goal is for it to be a wasm standard in the future. GC support is on the roadmap for the component model but not until after the next release (0.3). You might be interested in this: https://www.youtube.com/watch?v=W3f8AAte0LM

Perfect will check this out

Chris Fallin (May 21 2025 at 20:02):

To answer the immediate question

Is there anything that stops these 2 standard from coexisting?

The two coexist just fine. A module that uses APIs defined in WIT today (i.e., component imports) will transfer data for arguments and returns according to the "canonical ABI", which puts data in linear memory and allocates areas for that with cabi_realloc, as you may be referring to. A Wasm module can have both a linear memory and access to GC allocations, of course, so a toolchain/producer could generate code that does both.

To the broader "do they interact" question, they could interact if/when we have another ABI that maps WITs to GC types instead (i.e., something other than the "canonical ABI"). @fitzgen (he/him) has started to think about this and has discussed it with @Luke Wagner -- that's the part that Lann is referring to above.

Cwasi4wasm (May 22 2025 at 12:31):

Chris Fallin said:

To answer the immediate question

Is there anything that stops these 2 standard from coexisting?

The two coexist just fine. A module that uses APIs defined in WIT today (i.e., component imports) will transfer data for arguments and returns according to the "canonical ABI", which puts data in linear memory and allocates areas for that with cabi_realloc, as you may be referring to. A Wasm module can have both a linear memory and access to GC allocations, of course, so a toolchain/producer could generate code that does both.

To the broader "do they interact" question, they could interact if/when we have another ABI that maps WITs to GC types instead (i.e., something other than the "canonical ABI"). fitzgen (he/him) has started to think about this and has discussed it with Luke Wagner -- that's the part that Lann is referring to above.

Awesome thank you for the answer. Consequently does this means I can use the same tooling? If I have a GC standard in my wasm binary can I use the same adapters to upgrade it to a component?

Chris Fallin (May 22 2025 at 15:54):

I believe so, yeah -- this is one of those "in principle it should work and I can't think of why it shouldn't, but please try it and file a bug if it doesn't" sort of things

Cwasi4wasm (May 22 2025 at 15:55):

Awesome thank you!

Last updated: Dec 06 2025 at 06:05 UTC

Stream: wasmtime