I was optimistic about supporting WasmGC through ScalaNative (NIR), but it turned out to be quite difficult (or even impossible) for several reasons.
- ScalaNative’s C interop, especially around pointer handling and (stack) allocation. And part of the ScalaNative ecosystem relies on this C interop and cannot be ignored.
wasi-libc
may not work well with the ScalaNative generated WasmGC code, the code needs to be adapted to the ABI tool-conventions/BasicCABI.md at main · WebAssembly/tool-conventions · GitHub- Also,
wasm-ld
may not work with the WasmGC code, we need to fork and support it.
If we want to support Wasm through ScalaNative, the Emscripten/WASI-SDK way @WojciechMazur explored last year would be realistic. (but we might need to port GC for Emscripten like Porting Boehm to Emscripten · Issue #18251 · emscripten-core/emscripten · GitHub)
I’m not sure how it goes with cycle collection in Wasm on browser or Wasm component settings though.
Overall, if we want to go with WasmGC, Scala.js is indeed the way to go.
- Step 1: Support WasmGC in the browser
- Users will enjoy better performing Scala.js output.
- Step 2: Support WASI that works on Node.js
- WasmGC code developed in Scala.js can be deployed on servers running Node.js.
- Step 3: Support a pure WASI runtime (like wasmtime): wasmtime needs to support WasmGC, javalib and scalalib need to be rewritten based on WASI.
- The WasmGC code will work everywhere (where the runtime supports features including WasmGC), like edge, IoT devices (hopefully), and so on. But third-party Scala.js libraries won’t work.
- Step 4: Cross-compile Scala.js libraries that depend on JS semantics for WASI, and build the ecosystem on top of WASI.
- Third party Scala.js libraries will work with a pure WASI environment.
- Extra: Support for the Wasm component model (as host and guest) to interact with Wasm components developed by any other language.