Wasmtime currently seems to be unusable for runnin...

# webassembly

[Alexey Zolotarev]

Wasmtime currently seems to be unusable for running Kotlin-generated code, even in standalone mode it either fails with some internal assertions on GC types or with GC heap out of memory errors. I'm trying WasmEdge and in standalone mode it seems to work but when embedded in Rust any non-trivial Wasm function call ends up with an error. E.g. calling this function

fun main() {
    println("test")
}

or this:

fun main() {
    val x = "test"
    check(x[0] != 'x')
}

results in this:

[2024-12-04 14:44:27.909] [error] execution failed: null structure reference, Code: 0x414
[2024-12-04 14:44:27.910] [error]     In instruction: struct.get (0xc9) , Bytecode offset: 0x00001ede
Error: Core(Execution(AccessNullStruct)

Maybe someone encountered this?
Same embedded instance seem to be fine executing wasm binaries generated by Rust or AssemblyScript.

[Artem Kobzar]

You can check this MR: https://github.com/Kotlin/kotlin-wasm-wasi-template/pull/3
Long story short, the published version still doesn't support GC, but the dev version does. Additionally, you need to turn off exception handling usage by the next code:
https://github.com/Kotlin/kotlin-wasm-wasi-template/blob/main/build.gradle.kts#L40
After that, it should work.

[Alexey Zolotarev]

Wasmtime actually announced official Wasm GC support in the recently released version: https://bytecodealliance.org/articles/wasmtime-27.0, this is the version I was talking about. Actually I've tried a prerelease version before too and it had the same issues.

It can init a Kotlin-generated module but then it fails with this https://github.com/bytecodealliance/wasmtime/issues/9701 or this https://github.com/bytecodealliance/wasmtime/issues/9714#issuecomment-2517004021

[Alexey Zolotarev]

With WasmEdge I'm able to run Kotlin-generated code with wasmedge --enable-function-reference --enable-gc --enable-exception-handling but the embedded version which should be using the same shared lib fails with an error I mentioned above. Not clear how to debug it either - no stacktrace, nothing 🤕

[Artem Kobzar]

Oh, I see. Thank you for sharing.
Seems like the problem in their GC implementation.

[bashor]

Seems as bugs in VMs, please report issue in their trackers.

[bashor]

Please also share links here.

[Alexey Zolotarev]

I've created issues in the Wasmtime repo, links are in the comment above.

As for WasmeEdge I've asked in their chat, hopefully someone will be able to look into it. The thing is, it successfully executes the module in the standalone mode but fails with this error in the embedded mode even though the same shared lib should be used in both cases so maybe I'm doing something wrong. If this is confirmed to be a bug then I'll create an issue in their repo and will post a link here too.

[Charlie Tapping]

chasm runs kotlin wasm just fine 👀 https://github.com/CharlieTap/chasm

[Alexey Zolotarev]

Thanks! @Charlie Tapping, do you consider the runtime to be experimental? There is no built-in WASI 0.1 support, right? Also are there any benchmarks to compare it against other runtimes by any chance?

I know Kotlin/Wasm is itself considered alpha but hopefully it's not for long.

[Charlie Tapping]

Chasm is production ready in the sense it will compute you the correct result, it passes the official wasm testsuite. Performance wise I’ve only recently started to tune it so I would expect it to be slower than other runtimes, though on the jvm it seems to have acceptable performance for a bunch of different workloads I put it through… In regards to WASI there is a library being worked on by @Alexey Illarionov here which has chasm bindings https://weh.released.at/

[Alexey Illarionov]

Hello everyone. I’ve created a Kotlin Multiplatform library that implements host functions from the WASI Preview 1 specification: https://weh.released.at/.
It allows running WebAssembly code compiled for WASI in interpreters such as Chicory, Chasm, or GraalWASM.
This implementation (with a few minor exceptions) passes the Wasi-testsuite. Under the hood, it includes four different implementations of file system access functions for various targets: JVM (based on NIO), Apple, Linux, and Windows.

As a demonstration, I’ve prepared a small example that shows how to run code compiled for Kotlin/Wasm-WASI in other Kotlin Multiplatform targets: https://github.com/illarionov/wehdemo.
It’s similar to the kotlin-wasm-wasi-template example from the Kotlin/Wasm team, but instead of running the WebAssembly code on Node.js/Deno, it runs on a Chasm-based interpreter.
This project has two modules.
* The wasm-code module compiles Kotlin/Wasm code that uses WASI Preview 1 functions
* The chasm-runner module runs the compiled WASM binary in Chasm on JVM, macOS, Linux, and Windows targets.
For test code, I used the MonotonicTime example from the kotlin-wasm-wasi-template, and also some solutions for Advent Of Code 2024 puzzles by @ephemient (which are compiled for the wasmWASI target and include file reading).

At the moment, it’s difficult to find practical use for this. It’s mainly intended to demonstrate that, in the future, WASM/WASI code can be embedded into any other native code. Unfortunately, the performance of an Chasm interpreter is still not enough to be used in real projects for now.
In any case, feel free to try it out and share your feedback.

[Michael Paus]

@Alexey Illarionov Did you also try Chasm 0.9.3 because of its better performance and not only 0.9.2 as stated in the documentation?

[Alexey Illarionov]

@Michael Paus Yes, I have tried it. The performance in the new version is indeed better, but it is still not sufficient. For now, I decided to stick with the minimum version 0.9.2 because the MinGW target is disabled in version 0.9.3 and and I also had some issues with exceptions and memory consumption. The library works with version 0.9.3 as well, so end-users can still use it.