Why Chrome Enabled WebAssembly Garbage Collection (WasmGC) By Default (chrome.com) 56
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:
"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."
Great news (Score:5, Funny)
That's great news. That's going make my Ruby based C++ compiler run so much faster in Chrome.
Re: (Score:2)
KInd of silly as well IMHO, if 2 garbage trucks came to my door to pick up trash the second one would run much faster since it would have nothing to pick up. So, negligible impact IMHO or as least, not as bad as they make it sound.
Well then. (Score:2)
GC-based attacks (Score:2)
It sounds like a great plan, but I can't help but wonder if this will create a uniform surface for attackers trying to get at deallocated memory. I imagine the WasmGC folks are going to have a hard time convincing the Rust-on-Wasm folks to remove all their free()s and just trust WasmGC to do everything for them.
Re: GC-based attacks (Score:2)
I don't see what benefit you gain from it aside from saving a few kilobytes on your binary blob, which comes at the expense of slower code with a more complex runtime.
Re: (Score:2)
I imagine the WasmGC folks are going to have a hard time convincing the Rust-on-Wasm folks to remove all their free()s and just trust WasmGC to do everything for them.
WasmGC is a more efficient backend for languages with GC.
Rust doesn't use GC, so Rust programs can just ignore WasmGC and do what they're already doing.
Re: (Score:2)
WasmGC is a more efficient backend for languages with GC.
Why would it be? WASM runs at something like >50% native speed and a language provided GC knows a lot more about the language and an optimize things a lot better than a generic platform GC.
Re: (Score:2)
a language provided GC knows a lot more about the language and can optimize things a lot better than a generic platform GC.
[Citation needed]
Re: (Score:2)
Here is a starting-point: https://www.hboehm.info/gc/ [hboehm.info]
For more, I recommend implementing a few GCs, things will become _very_ obvious when you do.
Re: (Score:2)
The Erlang/Elixir VM, BEAM, has a garbage collector does exactly this. Erlang/Elixir is written in such a way that there are many concurrent processes with NO SHARED MEMORY between them. All interprocess comms is done by message passing and the processes cannot build pointer for variables that point to a address in another process's memory.
This means if a process dies the GC can throw out the entire heap for the process in one go, because there are no pointer references that point between the different per-
Re: (Score:2)
Not even the C folks will be convinced. I do think this could very well lead to a lot of problems and not only because of the mono-culture aspect.
What's the chance of WASM (Score:2)
becoming the next Java Applets and turning into a vector for crypto-mining pirates and other mayhem?
Re: (Score:2)
Re: (Score:1)
Thanks, Dr. Vaguoid.
Re: (Score:2)
Re: (Score:1)
I did read up, and opinions by experts vary widely. One interesting opinion is that if WASM is locked down tightly in a given browser or browser version, it won't be very practical, but loosening it up to access more resources and devices also opens breach risks.
Re: (Score:2)
Already has been for a few years.
Re: (Score:2)
But we were saved by the crypto-crash.
Re: (Score:1)
> But we were saved by the crypto-crash.
There's security-thru-obscurity, now there's security-thru-market-crash.
Re: (Score:2)
IMHO, java applets were great and we have lived several cycles of trying to re-invent basically the same thing since them.
So, I am going to play the conspiracy theorist here so take that with a grain of salt please... :)
It seems like java applets have got the same fate as anything else coming from defunct Sun Microsystems; A large conspiracy was setup by shady actors which even included brainwashing young developers into believing anything java was bad. Sun Microsystems was just to good and threatened too m
Re: (Score:1)
I believe we need something similar to Applets, as the DOM sucks rotting eggs, but Java Applets did have a lot of security holes, and took too long to download because they were hard to modularize based on feature usage, usually resulting in one-big-slow-download.
And the Java engine's version management was convoluted. Fixable, maybe, but they got bulldozed over by JS+Dom in the market place. And perhaps MS's underhanded tricks did play a part.
We do need a standard GUI engine that's designed with biz/crud/g
Can you run a Beowolf Cluster on WebAssembly? (Score:2)
Re: (Score:2)
TBH I haven't verified this claim, though, as I'm not quite sure how to run WebAssembly inside of one of my Emacs buffers, I guess I'll need to run Chrome in there first? Would be nice if there was a ready made ELPA package for this. Have any vim users tried this in one of their vim-based browsers yet?
Re: (Score:2)
Re: (Score:2)
memory-safe programming (Score:3)
Nothing says memory-safe programming quite like assembly language.
Re: (Score:2)
All high level languages compile down to assembly/machine code. The only exceptions are interpreted languages were performance takes a big hit.
Re: (Score:3)
Nothing says memory-safe programming quite like assembly language.
Nothing about WebAssembly means you are programming in assembly language. You can program WebAssembly in Rust if you want.
Re: (Score:2)
Real men program chips directly in Verilog. Nothing says "Glitchy logic" quite like Verilog.
Size does not matter (Score:4, Insightful)
At least not in this region. That it is apparently given as a major advantage makes me think something very fishy is going on here. The other thing is that GCs need to be designed for the language and task in question to have good performance. (Yes, I have implemented specialized GCs.) General purpose GCs are always mediocre and cannot do anything really well.
Re: (Score:3)
It does when it comes to web: I remember reading a study a few years ago that a fraction of a second delay would mean someone was less likely to read the page.
Smaller file, means faster load time - A big part of the reason behind WASM is improving load time and performance. It might not matter for a hello world but for larger apps, it probably does
Re: (Score:2)
At what, 4kB more? Remember that much more data will be loaded anyways. For example the image /. shows at the moment on the right is already 11kB. The home-page of /. is about 1MB.
Re: Size does not matter (Score:2)
If it's indeed 4k, then after, not much network overhead. My hunch says it should be more for something full fledged.
With that said, having a built in optional GC is not necessarily a bad idea, melted barrier to entry lower, easier to optimize. It's is they don't allow languages like rust to do their thing that's going to be a pain
Re: (Score:2)
Well, the article quoted something in th 4...7kB range. Some memory management should be already present in WASM.
Re: (Score:2)
melted barrier to entry lower, easier to optimize
Some of the Wasm proposals make the same trade that the JVM and CLR do, which is to move complexity from the compiler into the runtime. That technically makes things easier for the compiler writers, but only if the VM is a good match for the language. Aiming to be "language agnostic" by targeting common language types naturally, like all premature optimization, both adds complexity and reduces flexibility. I think that's incredibly short-sighted.
I guess that some of that can also get you smaller object c
Re: Size does not matter (Score:2)
Agreed, which is why I ended that sentence by saying it should be optional - so languages like rust who are not a match are not impeded
Re: (Score:2)
It will be optional. While you can theoretically put a GC on a language that does not support it (see Boehm–Demers–Weiser GC, for example), it requires code that takes the GC into account. Just putting it in there may well break everything.
Re: (Score:2)
That technically makes things easier for the compiler writers, but only if the VM is a good match for the language.
Exactly. And if it is not a good match, it may be pretty unusable and you have to bring your own memory management anyways.
I think that's incredibly short-sighted.
Not only that, it is a known problem and anybody that has some research should clearly see the problems. My take is that this is intended to make coding "easier", actually making it much harder when memory management matters. Essentially crappy engineering to support marketing. What else is new.
Binary size (Score:2)
$ aptitude show openjdk-11-jre
Package: openjdk-11-jre
Version: 11.0.20.1+1-0ubuntu1~22.04
State: installed
Automatically installed: yes
Multi-Arch: same
Priority: optional
Section: java
Maintainer: Ubuntu Developers
Architecture: amd64
Uncompressed Size: 649 k <===========
Re: (Score:2)
Sorry I don't see what you're attempting to show there. The size of the dpkg for openjdk-11-jre has nothing to do with the size of a compiled binary targeting WasmGC.
Next up: trackers & ads served up in wasm byte (Score:2)
And then you can kiss your adblocker goodbye.
Fuck Google.
Re: (Score:2)
Can you tell more about this? They always need to fetch contents from an ad server (e.g. "doubleclick.net"), which you can block by domain or IP. The entire ad contents could be served from the customer website (copy the ad images to "slashdot.org"), but that's something they could already be doing and they are not doing it. What can WebAssembly change? (I want to know.)
Re: (Score:2)
To simplify, adblockers inspect the web pages you request to figure out which images and javascripts they pull in, and filter out - in effect, rewrite - the web pages so they don't pull in unwanted content. If the webpages become compiled bytecode, the inspection and rewriting will become essentially impossible.
Think of it as monkey-patching Python code at runtime (which is easy because it's readable in plain text) vs monkey-patching compiled C code (which is almost impossible).
As for doubleclick,net, most
Re: (Score:2)
To simplify, adblockers inspect the web pages you request to figure out which images and javascripts they pull in, and filter out - in effect, rewrite - the web pages so they don't pull in unwanted content. If the webpages become compiled bytecode, the inspection and rewriting will become essentially impossible.
Most React webpages are already generated dynamically from minimized Javascript, so this isn't going to be much different. Wasm still doesn't really have access to the DOM.
The main ad blocker tool is the fact that ads come from a different server/domain than the webpage they are served on. That isn't likely to change anytime soon, because of the way the ad business is set up. It's designed that way based on social structure, not technical efficiency.
Re: (Score:2)
It's not difficult to imagine websites serving minimal HTML pages that pay lip service to the DOM and only serve to pull in the byte-compile wasm garbage that does the heavy lifting, because that's what most Javascript-heavy sites do already.
The difference is, you can patch Javascript before it runs. Good luck doing that with wasm - easily anyway.
Re: (Score:2)
Scheme (Score:1)
Garbage Collection (Score:2)
Isn't that basically browsing the web these days?
Re: (Score:2)
somebody mod this up, that was funny and insightful
Chrome does GC? (Score:2)
The first thing it can haul off to the dump is itself.