Why Chrome Enabled WebAssembly Garbage Collection (WasmGC) By Default
'In Chrome, JavaScript (and WebAssembly) code are both executed by Google's open source V8 engine — which already has garbage-collecting capabilities. "This means developers making use of, for example, PHP compiled to Wasm, end up shipping a garbage collector implementation of the ported language (PHP) to the browser that already has a garbage collector," writes Google developer advocate Thomas Steiner, "which is as wasteful as it sounds." "This is where WasmGC comes in." WebAssembly Garbage Collection (or WasmGC) is a proposal of the WebAssembly Community Group [which] adds struct and array heap types, which means support for non-linear memory allocation... In simplified terms, this means that with WasmGC, porting a programming language to WebAssembly means the programming language's garbage collector no longer needs to be part of the port, but instead the existing garbage collector can be used. Sometime on Halloween, Steiner wrote that in Chrome, WebAssembly garbage collection is now enabled by default. But then he explored what this means for high-level programming languages (with their own built-in garbage collection) being compiled into WebAssembly: To verify the real-world impact of this improvement, Chrome's Wasm team has compiled versions of the Fannkuch benchmark (which allocates data structures as it works) from C, Rust, and Java. The C and Rust binaries could be anywhere from 6.1 K to 9.6 K depending on the various compiler flags, while the Java version is much smaller at only 2.3 K! C and Rust do not include a garbage collector, but they do still bundle malloc/free to manage memory, and the reason Java is smaller here is because it doesn't need to bundle any memory management code at all. This is just one specific example, but it shows that WasmGC binaries have the potential of being very small, and this is even before any significant work on optimizing for size. The blog post includes two examples of WasmGC-ported programming languages in action: - "One of the first programming languages that has been ported to Wasm thanks to WasmGC is Kotlin in the form of Kotlin/Wasm." - "The Dart and Flutter teams at Google are also preparing support for WasmGC. The Dart-to-Wasm compilation work is almost complete, and the team is working on tooling support for delivering Flutter web applications compiled to WebAssembly."' -- source: https://developers.slashdot.org/story/23/11/12/0456220 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/
On Mon, 13 Nov 2023 08:39:15 +1300, Peter Reutemann quoted:
'In Chrome, JavaScript (and WebAssembly) code are both executed by Google's open source V8 engine — which already has garbage-collecting capabilities. "This means developers making use of, for example, PHP compiled to Wasm, end up shipping a garbage collector implementation of the ported language (PHP) to the browser that already has a garbage collector," writes Google developer advocate Thomas Steiner, "which is as wasteful as it sounds."'
Particularly if you have to implement your own memory-management scheme because the provided one doesn’t work right. People have built implementations of Python, Java and other languages entirely in WebAssembly. But if the underlying memory management doesn’t do what you need it to do, you have to forget it and reimplement your own. As far as I can tell from a quick skim of the spec <https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md>, there is no support for reference-counted memory management, only for pure GC. As you may know, languages like Python (at least the CPython implementation) and Perl use a hybrid scheme, where dynamically-allocated objects have a reference count attached to them, so objects can be immediately freed when the count goes to zero. This works for a lot of cases, except where one object contains a reference that directly or indirectly points back to itself. Then the counts for the objects in the cycle never go to zero, so you have to resort to a garbage collector to clean them up. I think the term for this is “ORC”, where the “O” actually represents the cycles, while the “RC” stands for “Reference Counting”. The simpler, not to say simplistic, alternative is “ARC”, which stands for “Automatic Reference Counting”, which really means “Reference Counting And Nothing Else”. It could be that this terminology comes from Nim <https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html>.
Tangentially, you mentioned a lot of languages and not my friend Christine's hoot which doesn't have this problem. https://spritely.institute/hoot/ Not that I use uncommon lisps. Compiler garbage collector extensions outside of language standards are normal because different compilers are fundamentally different, imagine my friend Hayley's parallel garbage collector for sbcl (idk, look it up) or de facto standard extensions such as trivial-garbage, and weak pointer support generally. Basically javascript isn't a popular language.
On Mon, 13 Nov 2023 19:33:20 +1300, Jake Waas wrote:
Tangentially, you mentioned a lot of languages and not my friend Christine's hoot which doesn't have this problem. https://spritely.institute/hoot/
Seems Hoot uses GC, which some of us were trying to avoid.
Compiler garbage collector extensions outside of language standards are normal because different compilers are fundamentally different, imagine my friend Hayley's parallel garbage collector for sbcl (idk, look it up) or de facto standard extensions such as trivial-garbage, and weak pointer support generally.
Weak references are an entirely separate issue. Python manages to have them with ORC. And it manages just fine with the one kind, versus, say Java, which has no less than three different kinds.
I meant that the way hoot compiles r?rs to wasm doesn't have the double-garbage-collector note about php in the previous email, and has other nice attributes related to the kind of difficult way it's implemented. Not wanting garbage collection at all is another kettle of fish... I think weak pointers are as per Haible 2005, so I'm not sure what a weak references without reference to garbage collection would be. Hayley chewed me out a while ago for quasi-historical dancing to avoid using available garbage collection: The garbage collectors being avoided in the 80s aren't a good depiction of or of the useability of modern garbage collectors (obviously she's an sbcl contributor, so.). Putting garbage collectors inside garbage collectors kinda sucks. I think even ecl's experimental wasm target avoids double garbage collectoring, but I didn't talk to Jack Daniel about it recently.
participants (3)
-
Jake Waas -
Lawrence D'Oliveiro -
Peter Reutemann