Re: [w3ctag/design-reviews] WebAssembly Garbage Collection extensions (Issue #814)

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



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/814#issuecomment-1518113738
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/814/1518113738@github.com>