WebAssembly Garbage Collection extensions

[ajklein]

Wotcher TAG!

I'm requesting a TAG review of the WebAssembly Garbage Collection (Wasm GC) proposal.

The GC proposal adds efficient support for high-level managed languages to WebAssembly, via struct and array types that enable language compilers targeting Wasm to integrate with a garbage collector in the host VM.

• Explainer: GC proposal overview
• Specification URL: MVP spec, MVP JS API
• Tests: https://github.com/WebAssembly/gc/tree/main/test/core/gc
• Security and Privacy self-review
• Primary contacts:
  • Adam Klein (@ajklein), Chromium feature owner (Google)
  • Andreas Rossberg (@rossberg), proposal champion (independent)
  • Thomas Lively (@tlively), GC subgroup chair (Google)
• Organization(s)/project(s) driving the specification: WebAssembly Community Group members, including Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification: Meeting notes
• External status/issue trackers for this specification: Spec issue tracker

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the work on this specification is currently being done: WebAssembly Community Group, CG Subgroup
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WebAssembly Working Group
• Major unresolved issues with or opposition to this specification: None; there is a high level of consensus for the current proposal, as evidenced by its state at Phase 3 of the Wasm CG process

You should also know that:

• VM implementations are under way in V8 (Chromium), JSC (WebKit), and SpiderMonkey (Firefox)
• Language toolchain implementations targeting Wasm GC are underway, including Java, Dart, Kotlin, and OCaml
• In web browsers, integration with the host VM means that Wasm and JS objects can participate in object graphs without creating uncollectible cycles
• Because the GC proposal has been under development for several years, some material in the repo may be out of date (e.g., the "MVP-JS.md" document is no longer part of the proposal)

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify ajklein

[ylafon]

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

[rossberg]

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: @.***>

[ajklein]

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.

[torgo]

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

[ajklein]

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.

[ylafon]

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