Hacker News Reader

Comment by j0e1 | Hacker News Reader

> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm. But that’s it.

Wow!

View on HN

It's very refreshing and good to see WASM is embracing GC in addition to non-GC support. This approach is similar to D language where both non-GC and GC are supported with fast compilation and execution.

By the way now you can generate WASM via Dlang compiler LDC [1].

[1] Generating WebAssembly with LDC:

https://wiki.dlang.org/Generating_WebAssembly_with_LDC

Does this allow for shrinking the WebAssembly.Memory object?

- https://github.com/WebAssembly/design/issues/1397

- https://github.com/WebAssembly/memory-control/issues/6

This is a crucial issue, as the released memory is still allocated by the browser.

Wasm GC is entirely separate from Wasm Memory objects, so no, this does not help linear memory applications.

No, I don't think it will. Pointers to managed objects are opaque, and aren't actually backed by the wasm memory buffer. The managed heap is offloaded.

Shrinking the memory object shouldn't require any special support from GC, just an appropriate API hook. It would, as always, be up to the application code running inside the module to ensure that if a shrink is done, that the program doesn't refer to memory addresses past the new endpoint.

If this hasn't been implemented yet, it's not because it's been waiting on GC, but more that it's not been prioritized.

I'm not familiar with WASM. Can someone explain why this is a good thing? How does this work with languages that do not have a garbage collector, like Rust?

I works very well, thank you for asking: https://rustwasm.github.io/book/

The answer was kind of known before hand. It was to enable the use of GCed languages like Python on Ruby to create WASM applications. Meanwhile, non-GCed languages like Rust, C and C++ were supposed to continue to work as before on WASM without breaking compatibility. This is what they seem to have finally achieved. But I needed to make sure of it. So, here are the relevant points from the WASM GC proposal [1]:

  * Motivation
  - Efficient support for high-level languages
      - faster execution
      - smaller modules
      - the vast majority of modern languages need it

  * Approach
  - Pay as you go; in particular, no effect on code not using GC, no runtime type information unless requested
  - Don't introduce dependencies on GC for other features (e.g., using resources through tables)

[1] https://github.com/WebAssembly/spec/blob/wasm-3.0/proposals/...

to also consider this one https://github.com/6over3/zeroperl

Note that the high level language needs a sufficient abstraction in its own runtime to allow substituting the Wasm GC for the runtime’s own GC. Work has been done for Java and Kotlin, but Python, C#, Ruby, Go can’t yet use the Wasm GC.

Agreed. That's what I guessed too. WASM GC is probably a low level component which high level languages can wrap to get their native/idiomatic GC behavior.

> Work has been done for Java and Kotlin

I'm unaware of this development. What did they do? Did they create an interface to the GC specification in the draft proposal?

Well, for Java it's actually a separate compiler that targets Wasm and integrates with WasmGC: https://github.com/google/j2cl The Google Sheets team used it for their calc engine: https://v8.dev/blog/wasm-gc-porting

For Kotlin it's similar but the compiler backend is from Jetbrains themselves, targets Wasm and adapts the Kotlin runtime to use WasmGC: https://kotlinlang.org/docs/wasm-overview.html. https://seb.deleuze.fr/introducing-kotlin-wasm/ has some low level detail on how Kotlin works with WasmGC.

A bit more on Kotlin/Wasm here, seems like also Dart/Flutter uses WasmGC: https://developer.chrome.com/blog/wasmgc#kotlin_wasm

https://github.com/dotnet/runtime/issues/94420 has some notes on why C# can't use WasmGC (yet?).

Good info! Thanks!

Non-GCed languages will continue to manage memory themselves. Previously, GCed languages that wanted to run on WASM had to have an implementation of their runtime including GC compiled to WASM. The idea or hope here is that those languages can use the built-in GC instead and slim down the amount of WASM that needs to be delivered to run the application to only include a minimal runtime. The current scenario is closer to if a web app or node app built with JavaScript had to ship a significant portion of V8 with it to function.

This will probably benefit Java applets targeting Wasm the most considering the huge size of their JVM.

Would not be surprised to see the typeinfo needing shipped taking up more space than the internal GC implementation it replaced :)

Hopefully Go as well.

Here's a fun example of a language that takes advantage of this: https://spritely.institute/hoot/

This seems less than ideal to me.

1. Different languages have totally different allocation requirements, and only the compiler knows what type of allocator works best (e.g. generational bump allocator for functional languages, classic malloc style allocator for C-style languages).

2. This perhaps makes wasm less suitable for usage on embedded targets.

The best argument I can make for this is that they're trying to emulate the way that libc is usually available and provides a default malloc() impl, but honestly that feels quite weak.

I don't see this as a problem in the JVM, where independently of what programming language you are using, you will use the GC configured on the JVM at launch.

That sounds like WASM is going into the Java direction. Is that really a good thing?

What do you mean by the Java direction? It's a virtual machine with GC support, so I guess in that regard it's similar to the JVM, CLR, BEAM, et al. If anything, those VMs show performance improvement and better GC over time and a strong track record of giving legacy software longevity. The place where things seem to fall apart over the long term is when you get to the GUI, which is arguably a problem with all software.

Java approach: create the JVM to support one language, so it has rich high-level concepts that are unfortunately skewed toward certain assumptions about language design, and it can be reused only for other languages that are similar enough.

WASM approach: start very low-level so C is definitely supported. Thus everything is supported, although every language has to roll its own high-level constructs. But over time more patterns can be standardised so languages can be interoperable within a polyglot WASM app.

Reply on news.ycombinator.com