We looked at this during a teleconference, and we were wondering about the end-user benefits of this. ie: for the end-user what does that change from direct memory management code added by the compiler when generating WebAssembly from those high-level languages

The vast majority of modern languages needs a GC. Very few of these languages have been ported to Wasm, and various implementers of high-level languages have signalled that they held off such ports due to lack of built-in GC support. We are now seeing implementations of Java, Kotlin, Dart, OCaml, Scheme, Erlang, and other languages being worked on, all of which target the proposed GC extension.

There are a number of technical reasons why Wasm-user-land solutions for GC are not particularly attractive:

• GC implementations are a worst-case scenario for Wasm, since they usually require a lot of unsafe low-level tricks to be efficient, some of which cannot easily be expressed in Wasm, or only with extra overhead, due to its safety restrictions (e.g., Wasm does not expose the stack, which a GC typically needs to walk).

• Developing an efficient GC is a huge amount of work, that would have to be repeated for every language runtime. Due to the aforementioned restrictions in Wasm, even pre-existing GCs cannot readily be ported, but often require the different or additional techniques (such as shadow stacks).

• GCs are big. For example, the Mono team reported that their GC alone compiles to more than half a MB of Wasm code. Having to download that much code for every web page running on a high-level language is not attractive, especially when the amount of actual user code is small otherwise.

• A user-land GC cannot reliably solve the problem of managing cross-heap references (and possibly cycles) between Wasm and JS.

• Due to JavaScript, web engines already have highly optimised GCs, with tens of man-years of engineering behind them. It would be a shame not to make them available to Wasm.

On 20. Apr 2023, at 03:53, Yves Lafon @.***> wrote:

We looked at this during a teleconference, and we were wondering about the end-user benefits of this. ie: for the end-user what does that change from direct memory management code added by the compiler when generating WebAssembly from those high-level languages — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

Thanks for taking a look, and for the question, @ylafon. As @rossberg points out, many languages would not even attempt to target WebAssembly without built-in GC support. The first two bullets thus focus on the advantages of Wasm GC support for compiler/toolchain authors.

In case it's helpful, I'll explicitly spell out how the other three items affect end-users:

GCs are big. For example, the Mono team reported that their GC alone compiles to more than half a MB of Wasm code. Having to download that much code for every web page running on a high-level language is not attractive, especially when the amount of actual user code is small otherwise.

This bullet already mentions the end-user benefit, but to be extra-explicit: reducing the size of applications by not forcing them to bundle a garbage collector reduces bandwidth costs & requirements for end-users, and improves loading performance (thus improving user experience).

A user-land GC cannot reliably solve the problem of managing cross-heap references (and possibly cycles) between Wasm and JS.

This reduces the risk of memory leaks in applications, thus reducing resource consumption for end-users.

Due to JavaScript, web engines already have highly optimised GCs, with tens of man-years of engineering behind them. It would be a shame not to make them available to Wasm.

This improves the runtime performance of applications using Wasm GC, thus improving the user experience compared to other approaches.

Hi! Thanks for the responses above. Can you provide some additional info on multiple implementations / multi-stakeholder support?

There are full implementations in Chrome, Firefox, and the Wasm spec reference interpreter. Safari has a partial implementation. There are also implementations under way in Wasm engines outside browsers, e.g. wasmtime and wamr.

There are toolchains for many programming languages, including Kotlin, Dart, Java, OCaml, and Guile (Scheme).

As a Phase 3 proposal in the WebAssembly Community Group, this proposal has broad support from members of the CG (who have to vote to advance the proposal to each Phase), which is why the initial issue linked the meeting notes as evidence. Let me know what more detail you'd like about multi-stakeholder support.

Hi and sorry for the delay, we discussed this during our last teleconference and agreed that we have no issue with this proposal.