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

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.

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

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