Implement the WebAssembly GC Proposal

[Srinivasa314]

Tracking issue for implementation of the WebAssembly GC proposal

Tasks

Preview Give feedback

1. List of future optimizations for Wasm GC performance #9351
   0 of 12
   cranelift:goal:optimize-speed performance wasmtime:ref-types +3
2. Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
3. Reuse linear memories, and our code to emit their bound checks, for Wasm GC heaps #9350
   cranelift:goal:optimize-speed performance wasmtime:ref-types +3
4. add gc support to general/differential fuzzing info
5. rewrite the table_ops fuzzer to hammer on all GC/reference types things
6. write an announcement blog post that we support Wasm GC
7. prototype wasm GC & component model canonical ABI support
8. support struct/array/i31 in wasmtime's C API
9. Panic when running Wasm gc program #9669
   bug wasm-proposal:gc +2
   
10. Wasm GC doesn't seem to collect garbage which results in GC heap out of memory errors #9701
    bug wasm-proposal:gc +2
    
11. Error assertion left == right failed on Wasm module init in Rust-embedded Wasmtime #9714
    bug wasm-proposal:gc +2
    
12. Error linking to function that takes a GC array ref. #9848
    bug wasm-proposal:gc wasmtime:ref-types +3
    

[sdeleuze]

FYI we are now able to run a Kotlin/Wasm HTTP server via KoWasm on Node.js and I would be happy to leverage Wasmtime to run it as soon as it will get GC support.

This would be a really good fit since we would like to leverage WASI Preview2+ and Wasm Component Model asap.

See also my blog post The huge potential of Kotlin/Wasm for more context.

[fitzgen]

Heads up: I am working on an RFC to work out the design of our Wasm GC support. I expect to start implementing Wasm GC once that RFC reaches consensus and merges and I've finished implementing Wasm tail calls.

[fitzgen]

RFC is up: bytecodealliance/rfcs#31

[tw-atroehrsm]

hey there! any updates on this front? Really looking forward to use Kotlin/WASM with this runtime.
For now only V8 is feasible, as it includes a GC and has implemented the proposal

[fitzgen]

There is work on parsing and validation, and refactors setting the stage for these things, happening in the wasm-tools repository, since we need to be able to parse and validate Wasm before we can compile and run it.

[smndtrl]

@fitzgen could you provide links to the issues over there? I want to keep track with the progress due to the impact on Kotlin

[fitzgen]

@smndtrl since bytecodealliance/wasm-tools#1346 merged, all GC spec tests are passing in wasm-tools.

You can look at https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md#incremental-implementation-plan and https://docs.wasmtime.dev/contributing-implementing-wasm-proposals.html to get an idea of what is still to be done.

[tw-atroehrsm]

So it there any timeline, roadmap when this will be available at least with the null GC?

this was merged in may 2023 so can be marked as done?

#5288

what could one do to support this effort?

[fitzgen]

The function references proposal still needs to be exposed in the embedder API.

I am actively working on that and the rest of getting Wasm GC implemented. Right now it mostly involves some refactoring to the runtime's internals to pave the way for future changes. Unfortunately, there isn't much that can be split out and implemented in parallel right now.

[fitzgen]

FYI: #7943 finishes the function references proposal and takes the first baby steps towards Wasm GC inside Wasmtime, adding support for Wasm GC's nofunc and a Config::wasm_gc(enabled) knob.

[oovm]

It looks like all gc types declarations are supported.

Can we create an issue to track the progress of the gc proposal, such as

• gc instruction support
• non-collection runtime
• baseline gc runtime

[fitzgen]

Yes all the types are supported now, but instantiating them is not implemented yet; I'm working on it. Then the various instructions. Then the collector itself. (Right now we are reusing the deferred reference-counting collector that Wasmtime already has, so we can collect some garbage, but not cycles).

Personally, I'm not a huge fan of opening a bunch of tracking issues for things already effectively tracked by this issue. Happy to cross-link more PRs here as they come in though.

[lppedd]

Hi there! Just wondering if there are noteworthy updates on this front.

[fitzgen]

All the struct-related instructions are implemented.

Almost done with array-related instructions.

Still to do:

• ref.test
• ref.cast
• branch-on-cast instructions
• conversions between anyref and externref
• support for funcrefs in the GC heap
• lots of various optimizations
• better pooling allocator integration

[fitzgen]

Two notes:

1. All array instructions other than array.{copy,init_elem} have been implemented. Those last two will be coming very soon.

2. Folks following this issue might also be interested in following List of future optimizations for Wasm GC performance #9351

[bashor]

@fitzgen Great news! Thanks for the updates!

[bashor]

@fitzgen, do I understand correctly that storing a funcref in a struct's field is not supported yet?

[fitzgen]

That was true before a few days ago. Now, funcrefs inside GC objects should be fully supported.

And FWIW, all Wasm GC spec tests are now passing on main!

[bashor]

@fitzgen, but I got the following error on dev build from f59cad10572b9618b300af9e8fecf2ce13dba373

thread 'main' panicked at crates/wasmtime/src/runtime/vm/gc/enabled/structref.rs:331:17:
not yet implemented: funcrefs in GC objects
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: wasmtime::runtime::vm::gc::enabled::structref::VMStructRef::initialize_field
   3: wasmtime::runtime::gc::enabled::structref::StructRef::_new
   4: wasmtime::runtime::vm::const_expr::ConstEvalContext::struct_new
   5: wasmtime::runtime::vm::const_expr::ConstExprEvaluator::eval
   6: wasmtime::runtime::vm::instance::allocator::initialize_instance
   7: wasmtime::runtime::instance::Instance::new_raw
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
zsh: abort      RUST_BACKTRACE=1 ./wasmtime -W function-references=y -W gc=y

[fitzgen]

@bashor ah! looks like I missed a spot, thanks for finding it. FWIW, I think this should only be reachable from const expressions and host APIs. Will whip up a fix in a minute.

[fitzgen]

@bashor fix is over in #9454 !

[bashor]

@fitzgen Thanks!

Now it works! 🚀 https://x.com/bashorov/status/1844725893752553957

[fitzgen]

@bashor awesome!! Thanks for kicking the tires :)

[hoangpq]

Hi @bashor

I'm interested in running Kotlin WASI on Wasmtime, so I gave it a try, but I encountered an error. Do you have any ideas

RUST_BACKTRACE=1 ./target/debug/wasmtime -W function-references,gc ./kotlin-wasm-wasi-example-wasm-wasi.wasm
Error: failed to parse WebAssembly module

Caused by:
    exceptions proposal not enabled (at offset 0x6750)

Envs:

• Wasmtime: debug build from Wasmtime main branch
• Wasm from https://github.com/Kotlin/kotlin-wasm-wasi-template

[alexcrichton]

@hoangpq you might be interested in this comment perhaps. Wasmtime doesn't yet implement the exception-handling proposal for WebAssembly, so Kotlin won't run until that's implemented.

[hoangpq]

Thank you @alexcrichton.

[bashor]

Hi, @hoangpq!

You can uncomment/add these lines to prevent using EH by Kotlin/Wasm toolchain.

Note that the option was added only to allow earlier experimentation with VMs with limited/lack of EH support. In this mode, throwing an exception will lead to a trap (~program termination).

[hoangpq]

Got it. Thanks, @bashor.

[vouillon]

@fitzgen I get the following error:

thread 'main' panicked at crates/wasmtime/src/runtime/values.rs:919:50:
not yet implemented: eqref
stack backtrace:
   0: rust_begin_unwind
             at /build/rustc-1.80-R0vcdR/rustc-1.80-1.80.1+dfsg0ubuntu1/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /build/rustc-1.80-R0vcdR/rustc-1.80-1.80.1+dfsg0ubuntu1/library/core/src/panicking.rs:72:14
   2: wasmtime::runtime::values::Ref::_matches_ty
             at ./crates/wasmtime/src/runtime/values.rs:919:50
   3: wasmtime::runtime::values::Val::_matches_ty
             at ./crates/wasmtime/src/runtime/values.rs:193:55
   4: wasmtime::runtime::values::Val::ensure_matches_ty
             at ./crates/wasmtime/src/runtime/values.rs:213:12
   5: wasmtime::runtime::gc::enabled::arrayref::ArrayRef::_new
             at ./crates/wasmtime/src/runtime/gc/enabled/arrayref.rs:276:9
   6: wasmtime::runtime::vm::const_expr::ConstExprEvaluator::eval
             at ./crates/wasmtime/src/runtime/vm/const_expr.rs:301:33
   7: wasmtime::runtime::vm::instance::allocator::initialize_globals
             at ./crates/wasmtime/src/runtime/vm/instance/allocator.rs:800:13

[fitzgen]

@fitzgen I get the following error:

Looks like I missed a spot! Thanks for the report. Can you share the test case and steps to reproduce? Either here or in a new issue is fine. Thanks!

[vouillon]

I was trying this piece of code: bdd.zip
Using the following command:

./target/debug/wasmtime -W all-proposals=y ./bdd.wasm

[fitzgen]

Thanks! I'll take a look soon

[whyoleg]

Hey @fitzgen! During experiments with Kotlin Wasm WASI on Wasmtime I found several issues.
The code is here and produced Wasm file is here. Executed by running dev version of wasmtime:

wasmtime -W function-references,gc -D logging=y kotlin.wasm

Overall, every line from the example above produces an error on it's own :)

First four lines produces the following stack trace:

thread 'main' panicked at /Users/runner/work/wasmtime/wasmtime/crates/slab/src/lib.rs:387:14:
id from different slab
stack backtrace:
   0:        0x103470b5c - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
   1:        0x10348f690 - core::fmt::write::ha36a8060c13608ea
   2:        0x10346c724 - std::io::Write::write_fmt::h431832c8ebcc85c9
   3:        0x103471b68 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
   4:        0x103471718 - std::panicking::default_hook::h4ebc6eb4ae179807
   5:        0x1034725e4 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
   6:        0x103472010 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
   7:        0x103471020 - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
   8:        0x103471cd8 - _rust_begin_unwind
   9:        0x10350d854 - core::panicking::panic_fmt::h410d3f147658259b
  10:        0x10350d824 - core::option::expect_failed::h1b731afdb81ee447
  11:        0x102b395d8 - wasmtime::runtime::vm::libcalls::get_interned_func_ref::h1699d9d932a55f6c
  12:        0x104747638 - <unknown>

And the last line produces the following:

thread 'main' panicked at /Users/runner/work/wasmtime/wasmtime/crates/slab/src/lib.rs:203:9:
assertion failed: index <= Slab::<()>::MAX_CAPACITY
stack backtrace:
   0:        0x105b98b5c - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
   1:        0x105bb7690 - core::fmt::write::ha36a8060c13608ea
   2:        0x105b94724 - std::io::Write::write_fmt::h431832c8ebcc85c9
   3:        0x105b99b68 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
   4:        0x105b99718 - std::panicking::default_hook::h4ebc6eb4ae179807
   5:        0x105b9a5e4 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
   6:        0x105b99fe8 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
   7:        0x105b99020 - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
   8:        0x105b99cd8 - _rust_begin_unwind
   9:        0x105c35854 - core::panicking::panic_fmt::h410d3f147658259b
  10:        0x105c358c0 - core::panicking::panic::hee236ca94fc05047
  11:        0x1052615a8 - wasmtime::runtime::vm::libcalls::get_interned_func_ref::h1699d9d932a55f6c
  12:        0x106e6fd18 - <unknown>

It works with Node.js and WasmEdge and outputs:

Class@687611678
[1, 2, 3]
[REALTIME, MONOTONIC]
true
true

687611678 is a hash code, so it could change per execution

Hope this is fine to leave this here :)

[fitzgen]

Hey @fitzgen! During experiments with Kotlin Wasm WASI on Wasmtime I found several issues.

Thanks for reporting the issue! I just got back from vacation and am slowly catching up on things. Will take a deeper look soon.