Plan for GC and beyond

[keithw]

The function-references and gc proposals are going to be merged into the spec soon (as well as the "v4" revision of the exception-handling proposal, which we don't support yet). It could be good to talk about our plan for supporting these features in WABT. I think there's a few options to put on the table:

• We work on the current best-effort basis to update our exception-handling support and finish the implementation of function-references and gc (in the binary/text readers/writers, the interpreter, and wasm2c). I'm not sure who has a ton of spare cycles for this, but if there is continued interest in WABT, I and other contributors will probably eventually make it happen. Could take a long time though, and I'm a little nervous about losing community trust/interest if we allow WABT to fall behind the living spec for too long.
• We try to (re-)increase investment of engineering resources in WABT by some of the companies who use it. Based on conversations at the CG meeting, this seems like a bit of a long shot, but maybe I misread the situation or there is something these companies would want from us that we could provide. (E.g. how to make a persuasive case for Google and Mozilla to devote more engineering resources or to find a way to pay Igalia or others to start contributing more again.)
• We deprecate most of the WABT tools except for wasm2c, which we'd port to run in binaryen. An upside is that binaryen attracts a lot of investment/velocity and seems to be Google's focus right now in terms of non-browser Wasm tools, and wasm2c would get to ride its coattails; downside is that binaryen isn't really intended (as I understand it) as a spec-conforming implementation of a Wasm binary/text reader/writer + validator/interpreter, given its IR that is slightly different from Wasm. (And, smaller point, binaryen currently seems to be much slower than WABT at some operations like a wasm-merge.) So the community would lose that part of WABT's benefits.
• We replace the internals of WABT with the Bytecode Alliance's Rust wasm-tools project, and port wasm2c to run in wasm-tools. Upside is that this is also a heavily depended-on building block from the BA folks and a newer Rust codebase that also passes the spec tests, and it might be worthwhile to combine our efforts (aiui there are minor differences, e.g. I think wasm-tools can't currently write the folded text format which seems minor and probably addressable); downside is that this would be a pretty avulsive change (moving to Rust among other things) and would really need to have buy-in, might lose a lot of the current contributors, and would take significant investment to pull off. (Edit: and I also don't know how performance compares with WABT on huge modules.)

I don't think anything is forcing us to make a decision here, but tentatively I'd rather make one than sort of avoid it.

[sbc100]

Without addressing the rest of the questions here I would note the binaryen does have a new text parser that is nearing completion that will be able to be fully spec compliant. IIUC (@tlively will correct me) it should allow binaryen to then run the full spec tests in their upstream form.

[kripken]

[option 3] We deprecate most of the WABT tools except for wasm2c, which we'd port to run in binaryen. An upside is that binaryen attracts a lot of investment/velocity and seems to be Google's focus right now in terms of non-browser Wasm tools, and wasm2c would get to ride its coattails;

That is accurate I think. Binaryen is proving really useful as an optimizer for WasmGC content on multiple languages, with speedups and code size improvements that are pretty significant (e.g. 2x faster for Java). So I expect our investment there to continue.

Note that porting wasm2c to Binaryen could benefit from that optimizer as well, as wasm2js already does: wasm2js runs some specific optimization passes aimed to help JS execution speed (the IR is designed for that kind of thing, and maybe we'll find ideas for wasm2c).

For those reasons I think porting wasm2c to Binaryen can make sense. As a Binaryen developer I'd support that.

Regarding the downsides:

binaryen isn't really intended (as I understand it) as a spec-conforming implementation of a Wasm binary/text reader/writer + validator/interpreter, given its IR that is slightly different from Wasm. (And, smaller point, binaryen currently seems to be much slower than WABT at some operations like a wasm-merge.) So the community would lose that part of WABT's benefits.

Correct, Binaryen is an optimizer, not a general-purpose tool. It constructs a full IR for its input, in particular, which is why it can be slower compared to a tool that just scans the wasm in-place. And it doesn't round-trip wasm binaries perfectly.

Overall I'd say wasm2c could be ported to Binaryen, but the non-wasm2c tools could not. So one possible path to consider here could be (which combines two of your ideas @keithw):

• Port wasm2c to Binaryen.
• Rely onwasm-tools for wabt's other current tools, like text-to-binary, binary-to-text, objdump, etc., and contribute there.

I don't know enough about the status and momentum of those parts of wasm-tools, but there does seem to be a lot of overlap between wabt and wasm-tools, so maybe there is an opportunity to collaborate more there.

[soywiz]

Hey folks 👋 I'm the author of a VideoGame engine and libraries using Kotlin and did some tools regarding wasm myself, and I'm interested in the evolution of wasm2c + GC. I'm specially interested into being able to generate C code calling native libraries like SDL/Opengl from Kotlin WASM.
Not sure if it makes sense in this context reading the situation of this, but willing to contribute and/or at least betatest if possible either if it is here or ported to Binaryen. (I already commented in the irc, but doesn't seems to be too much activity there so decided to join this conversation here too).

[anuraaga]

Hello - my understanding of this issue is it's not necessarily specific to GC but about features in any new Wasm proposal. If that understanding seems off let me know and I can file a different one.

From what I can tell, currently wast2json does not support the threads spec tests

https://github.com/WebAssembly/threads/tree/upstream-rebuild/test/core/threads

wast2json has been very important for wazero to be able to execute spec tests and I'm wondering if there is a reasonable path forward to be able to use it for threads, it looks like the updates to the parser could be very significant. @sbc100 is threads support also in scope for the binaryen parser?

[kripken]

@anuraaga The binaryen parser already supports the threads proposal (without that, it would not be able to optimize pthreads content in Emscripten, for example, so that was implemented quite some time ago already).

[anuraaga]

@kripken Ah sorry if it was confusing, I meant the thread invocation syntax in the linked test cases, not atomics (I wish the proposal was caller Webassembly atomics instead of threads...). I don't know if this is the correct place to look but I don't see any IR related to those thread commands, which would make sense since they don't translate to Wasm IIUC, only test harness commands

https://github.com/WebAssembly/binaryen/blob/436d6399d2e915490f980f7f8193e84dc7ed215f/src/wasm-s-parser.h#L311

Would parsing those test-specific commands also be in scope?

[tlively]

Yes, I think parsing the full wast scripting language including threads extensions should be in-scope for the new parser, since the end point for that project is to be able to run all the upstream spec tests. I've added that to the list of remaining issues here: WebAssembly/binaryen#6208.

[alexcrichton]

👋 wanted to drop in as someone who works on wasm-tools and say that I'm happy to help out if that's the direction wabt maintainers/users feel is best.

From a maintenance perspective I can perhaps add some color on the wasm-tools side of things as well. The core libraries (Rust crates) like wasmparser are likely to be well-maintained for quite some time as they're the foundation for Wasmtime and a number of other libraries which have variety of stakeholders. The CLI, however, is mostly maintained by me at this time and thus has a pretty small bus factor. While useful to many folks also working on Wasmtime and such I've found that the CLI and some of the surrounding commands/crates are only "secondarily useful" so they don't receive quite as much love as they could.

Not to say the BA or folks are disinterested in the CLI itself of course, mostly just instead saying that while core functionality will likely be well-looked-after some of the surrounding bits are likely ripe for more interest and/or help maintaining.

[SoniEx2]

• We work on the current best-effort basis to update our exception-handling support and finish the implementation of function-references and gc (in the binary/text readers/writers, the interpreter, and wasm2c). I'm not sure who has a ton of spare cycles for this, but if there is continued interest in WABT, I and other contributors will probably eventually make it happen. Could take a long time though, and I'm a little nervous about losing community trust/interest if we allow WABT to fall behind the living spec for too long.

Personally, we would like to see this happen. wasm GC scares us, but other than that...

[spotandjake]

Maybe the wasm specTec work could be used in the future to help reduce the burden of maintenance.