Srinivasa314 opened issue #5032:
Feature
Implement the WebAssembly GC proposal
Benefit
Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach
- The WebAssembly stack cannot be scanned for GC roots. As of now a shadow stack is usually used but it is not ideal.
- Webassembly modules of GC languages are huge as they must include the GC
- GCs implemented under WASM are less efficient and slower
Implementation
Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted
sdeleuze commented on issue #5032:
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 commented on issue #5032:
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 assigned issue #5032 (assigned to fitzgen):
Feature
Implement the WebAssembly GC proposal
Benefit
Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach
- The WebAssembly stack cannot be scanned for GC roots. As of now a shadow stack is usually used but it is not ideal.
- Webassembly modules of GC languages are huge as they must include the GC
- GCs implemented under WASM are less efficient and slower
Implementation
Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted
fitzgen commented on issue #5032:
tw-atroehrsm commented on issue #5032:
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 commented on issue #5032:
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 commented on issue #5032:
@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 commented on issue #5032:
@smndtrl since https://github.com/bytecodealliance/wasm-tools/pull/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 commented on issue #5032:
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?
what could one do to support this effort?
![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)
https://github.com/bytecodealliance/wasmtime/pull/5288 is merged since May
tw-atroehrsm edited a comment on issue #5032:
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?
![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)
https://github.com/bytecodealliance/wasmtime/pull/5288what could one do to support this effort?
tw-atroehrsm edited a comment on issue #5032:
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?
![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)
https://github.com/bytecodealliance/wasmtime/pull/5288what could one do to support this effort?
tw-atroehrsm edited a comment on issue #5032:
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?
![image](https://github.com/bytecodealliance/wasmtime/assets/116177334/822311d1-2577-4811-82c5-1fa09c2fc138)https://github.com/bytecodealliance/wasmtime/pull/5288
what could one do to support this effort?
fitzgen commented on issue #5032:
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 commented on issue #5032:
FYI: https://github.com/bytecodealliance/wasmtime/pull/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 aConfig::wasm_gc(enabled)
knob.
oovm commented on issue #5032:
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 commented on issue #5032:
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 commented on issue #5032:
Hi there! Just wondering if there are noteworthy updates on this front.
fitzgen commented on issue #5032:
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
andexternref
- support for
funcref
s in the GC heap- lots of various optimizations
- better pooling allocator integration
fitzgen commented on issue #5032:
Two notes:
All array instructions other than
array.{copy,init_elem}
have been implemented. Those last two will be coming very soon.Folks following this issue might also be interested in following https://github.com/bytecodealliance/wasmtime/issues/9351
bashor commented on issue #5032:
@fitzgen Great news! Thanks for the updates!
bashor commented on issue #5032:
@fitzgen, do I understand correctly that storing a
funcref
in a struct's field is not supported yet?
fitzgen commented on issue #5032:
That was true before a few days ago. Now,
funcref
s inside GC objects should be fully supported.And FWIW, all Wasm GC spec tests are now passing on
main
!
fitzgen edited issue #5032:
Feature
Implement the WebAssembly GC proposal
Benefit
Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach
- The WebAssembly stack cannot be scanned for GC roots. As of now a shadow stack is usually used but it is not ideal.
- Webassembly modules of GC languages are huge as they must include the GC
- GCs implemented under WASM are less efficient and slower
Implementation
Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted
```[tasklist]Tasks
~~~
fitzgen edited issue #5032:
Feature
Implement the WebAssembly GC proposal
Benefit
Most modern languages use GC. The current way to do it is on top of linear memory. However there are disadvantages to this approach
- The WebAssembly stack cannot be scanned for GC roots. As of now a shadow stack is usually used but it is not ideal.
- Webassembly modules of GC languages are huge as they must include the GC
- GCs implemented under WASM are less efficient and slower
Implementation
Wasmtime already supports stack maps and stack scanning but the rest has to be implemnted
```[tasklist]Tasks
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
~~~
bashor commented on issue #5032:
@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 commented on issue #5032:
@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 edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
~~~
fitzgen commented on issue #5032:
@bashor fix is over in https://github.com/bytecodealliance/wasmtime/pull/9454 !
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [ ]
wasmtime::NoneRef
host API type~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [ ]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [ ]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [ ]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
~~~
bashor commented on issue #5032:
@fitzgen Thanks!
Now it works! :rocket: https://x.com/bashorov/status/1844725893752553957
fitzgen commented on issue #5032:
@bashor awesome!! Thanks for kicking the tires :)
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [x]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [x]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
- [ ] Implement the null GC described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] Implement the null GC described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [x]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the null GC described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [x]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the null GC described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
~~~
hoangpq commented on issue #5032:
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 commented on issue #5032:
@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 commented on issue #5032:
Thank you @alexcrichton.
bashor commented on issue #5032:
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 commented on issue #5032:
Got it. Thanks, @bashor.
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [x] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [x]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
- [ ] Implement the null GC described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [x]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
- [x] Implement the null GC described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [x]
wasmtime::NoneRef
host API type- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
- [ ] Implement the null GC described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
~~~
fitzgen edited issue #5032:
Tracking issue for implementation of the WebAssembly GC proposal
```[tasklist]
Tasks
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9351
- [ ] Implement the copying collector described in the RFC: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md
- [ ] https://github.com/bytecodealliance/wasmtime/issues/9350
- [ ] add gc support to general/differential fuzzing info
- [ ] rewrite the
table_ops
fuzzer to hammer on all GC/reference types things- [ ] write an announcement blog post that we support Wasm GC
- [ ] prototype wasm GC & component model canonical ABI support
- [ ] support struct/array/i31 in wasmtime's C API
~~~
vouillon commented on issue #5032:
@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 commented on issue #5032:
@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 commented on issue #5032:
I was trying this piece of code: bdd.zip
Using the following command:./target/debug/wasmtime -W all-proposals=y ./bdd.wasm
fitzgen commented on issue #5032:
Thanks! I'll take a look soon
whyoleg commented on issue #5032:
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 runningdev
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>
Hope this is fine to leave this here :)
whyoleg edited a comment on issue #5032:
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 runningdev
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 :)
Last updated: Nov 22 2024 at 16:03 UTC