I am currently trying to create an executable WebAssembly project for Node and set up a project that uses Multiplatform version

1.8.20-dev-5802

. I managed to get it working in that I get an .mjs file and a .wasm file, but when I try to execute the .mjs file with Node 19.4.0 with a completely empty main function, the execution fails with the following message:

CompileError: WebAssembly.Module(): Compiling function #13:"kotlin.text.checkRadix" failed: Invalid opcode 0xe3 @+9238

When I try to open the produced file in an online WASM to WAT converter, it also fails. How can there be an invalid opcode? Am I missing any flags that I have to enable in Node? I am currently using

--experimental-wasm-eh

,

--experimental-wasm-typed-funcref

and

--experimental-wasm-gc

. From what I have seen after a quick Google search, the opcode 0xe3 doesn't seem to be valid currently anyways, not even when considering all active proposals.

This is expected due to WebAssembly GC evolution, with Kotlin/Wasm 1.8.20 you need Node 20 (canary). You can install it with:

NVM_NODEJS_ORG_MIRROR=<https://nodejs.org/download/v8-canary> nvm install v20.0.0-v8-canary202212266b2b946a63
nvm use v20.0.0-v8-canary202212266b2b946a63

And/or configure your build like https://github.com/skuzmich/kotlin-wasi-bindings-experiments/blob/main/build.gradle.kts

That seems to work, thanks. The repository you linked also seems very interesting, it seems to expose WASI calls to Kotlin? I was thinking if it would be possible to do it the other way around. Instead of designing your Kotlin programs to use these WASI calls, would be maybe be possible to compile a WASM program normally and replace the JS glue code with WASI calls from within the WASM executable, preferrably also written in Kotlin? That would require the names of those imported JS functions to be stable of course, which they don't really look like they are...

Glad it works. About WASI I am doing upcoming development on https://github.com/sdeleuze/kowasm. I am not sure what is your use case for what you describe for WASI, could you ellaborate?

Instead of designing your Kotlin programs to use these WASI calls, would be maybe be possible to compile a WASM program normally and replace the JS glue code with WASI calls from within the WASM executable, preferrably also written in Kotlin? That would require the names of those imported JS functions to be stable of course, which they don’t really look like they are...

At some point, would would likely have a version of stdlib without JS, with WASI imports only.

Ah ok, that was about that, so yeah this would be the best outcome.

I am not sure what is your use case for what you describe for WASI, could you ellaborate?

I am trying to compile a standalone WASM binary that I can run externally without any JS glue, which seems like is not really currently possible... But that's why I am asking if there are any ugly hacks to do it anyways 😄

It is planned. Also, having a non-JS Wasm runtime with GC support (or progress in this direction) would deficiently bump the priority of non-JS stdlib on our side.

Yep I discussed that with Wasmtime team at some point but https://github.com/bytecodealliance/wasmtime/issues/5032 require significant effort so no short term plans. Another way to move forward would be https://github.com/WebAssembly/binaryen/issues/4590.

I assume that it is implemented in Node because it reuses V8's GC? It's a shame that the current non-JS runtimes don't at least have stub implementations available as far as I can tell. Even if it used a bump allocator or something that never frees the memory, one could at least run and test simple programs on there. I assume that Kotlin/Native has to ship a GC though, would it be possible to reuse that one by compiling it to WASM as well?

Yep that's the reason. Kotlin/Native Wasm support with GC is a dead end and will be removed, Kotlin/Wasm with GC is the way to move forward for a lot of reasons.

I have never tried using the WASM target for Kotlin/Native so I wasn't aware that the idea of shipping a GC has been tried before... It sounded very complicated anyways but I thought that the Kotlin devs aren't above shipping complicated software to work around host limitations as that's kind of their hole thing...

I think that will be doable via migrating to using Kotlin/Wasm standard libraries and other multiplatform libraries once supported (or using KoWasm when mature enough in the interim).

I was looking at this mapping in the JS code and technically you should be able to translate them to WASI calls, right? The only thing that I am unsure about is that these look like compiler implementation details that might change at any time.

These is implementation detail, and can change, yes. Maybe someday we’ll make these names stable, but it is not a priority. It is better to use this JS file as-is for now (all Wasm GC runtimes currently support JS, so this shouldn’t be a problem), and wait for non-JS stdlib.

Okay, thanks!

Not supported yet https://github.com/nodejs/uvwasi/issues/183

Oh, that makes a lot of sense then. I couldn't find anything about that on Google and I didn't think to check the issues. Are there any other parts of the WASI spec that are unimplemented?