3 ms·

> Option 1: you rely on every single developer to be careful and make no memory-leaking mistakes. Nobody is expecting every single developer to carefully write

> Option 1: you rely on every single developer to be careful and make no memory-leaking mistakes. Nobody is expecting every single developer to carefully write their own garbage collector. WASM is a compilation target for other languages. The language you're compiling defines how memory management works, be that C / Zig (do it yourself), Rust (compile time borrow checker), Swift/ObjC (Rc / arc) or Go/JS/Java/C# (full garbage collector built into the language). For GCed languages like Go or C#, the design choice WASM makes is between: 1. The compiler injects its own garbage collector into the created webassembly modules, just like it does when compiling native binaries. or 2. The webassembly virtual machine provides a garbage collector that any compiled code can use. The benefit of (1) is that it makes webassembly virtual machines simpler and safer. (This is what the GP comment wants). (Also compilers can do language-specific optimizations to their own GC.) But (2) has a bunch of benefits too: - The GC can be higher performance (its not written in webassembly). - Interoperability between WASM bundles written in different languages is much better. Eg it'd be easier for Go in a WASM bundle to talk to JS in the browser. Or Go and C# code to interoperate via WASM. - The .wasm modules for GCed languages will be much smaller, since they don't need to compile in a garbage collector. The Go/Java/C# you write will be the same. The difference is who provides the garbage collector. Your compiler, or the WASM virtual machine?

omeze 4y ago
do you have an opinion on which direction is more likely? naively I'd say 2 would be better since it'd require less language-specific toolchain work for a better devexp for the end developer.
- josephg 4y ago
  Option 1 - Webassembly without a built-in garbage collector - exists today. You can compile Go or C# to WASM today, and it will output a WASM module with an embedded garbage collector. There's a draft proposal to add a built in garbage collector (option 2) to WASM. I have no idea what the current status is - maybe someone involved can chime in. I suspect some version of the WASM GC spec will land eventually. When it does, languages like Go, C# and Java should start to become competitive with javascript as frontend web languages. https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc
  - aidenn0 4y ago
    How does it find the GC roots on the stack?
    - flohofwoe 4y ago
      AFAIK garbage collected 'objects' are completely separate from regular WASM heap allocations and tracked directly by the WASM VM (I may be wrong though, but details are here: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...)
      - aidenn0 4y ago
        I meant in e.g. the C# runtime...
  - brabel 4y ago
    WASM GC is already in the implementation phase[1], which means, IIUC that it's a matter of time for it to make into the official standard (i.e. the spec itself is mostly done now)... the implementations are behind a feature flag in Chromium[2] and Firefox seems to be far into making it available, see the current list of WASM-related issues they're working on[3]: [1] https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals [2] https://chromestatus.com/feature/6062715726462976 https://chromestatus.com/feature/6062715726462976 [3] https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=JavaScript%3A%20WebAssembly&bug_status=__open__ https://bugzilla.mozilla.org/buglist.cgi?product=Core&compon...
- deleted 4y ago
  [deleted]
kaba0 4y ago
> The benefit of (1) is that it makes webassembly virtual machines simpler and safer Why would that be safer at all?
- josephg 4y ago
  It lowers the surface area for bugs (and thus vulnerabilities). WASM is gloriously simple right now. Adding a garbage collector dramatically increases the security surface area.
  - kaba0 4y ago
    I do believe that the tradeoff is well worth it though. We can write very high quality software (think of JVM, V8, etc) when the incentives are different than the 163748th CRUD app. Otherwise we could just as well use a trivial brainfuck interpreter as target, that won’t have a vulnerability ever.
still_grokking 4y ago
This comment repeats a fundamental error and misunderstanding: WASM is (currently) not able to be a compilation target for an efficient GC implementation. It lacks features needed to be able to implement GCs reasonably, like memory barriers. So 1. is out of scope if you don't want a bloated super slow language runtime running on top of WASM (like e.g. Blazor). The issue is known since the very beginning. Nobody in charge is willing to solve it. Also 2. is not happening, even it was discussed also since many years. But that makes actually "sense" form the WASM people's perspective: WASM was never meant to by concurrency to JS in the browser! WASM is merely a performance booster for where JS sucks (like numerical code). That WASM will allow to use other languages (and their ecosystems) in the browser is just a day dream of some. The companies behind "the web platform" won't give up on their billions worth of investments into the JS ecosystem. So no, GC languages other than JS won't ever run "natively" on the browser in a meaningful way. WASM is crippled on purpose in this regard, and as long as the current stack holders continue to control "the web platform" this won't change.
- mike_hearn 4y ago
  > WASM is (currently) not able to be a compilation target for an efficient GC implementation. Even if it was, there are other problems that mean the dream of being able to use alternative languages and runtimes on the web is far off, if it even ever happens at all. As a hobby I'm writing a design doc for an alternative non-web system design. It enumerates some of those problems and proposes solutions, along with other dissatisfying aspects of the web (e.g. the unimplementably large size of the web specs). https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI4J5AbxVWKEeYr6hscT8/edit?usp=sharing https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI... It's designed to be a very lightweight set of layered specs and projects that are way cheaper to implement than HTML5, can be developed and deployed incrementally whilst providing value from the start and which places other runtimes on a level playing field vs HTML. It also addresses many of the details you need to tackle for any serious web-like system such as transiency, sandboxing, tabbed WM, cache privacy, portability and hyperlinking. I sent it to Ian Hixson who found it interesting, but of course the sticking point is funding models. Being way cheaper to implement than the web doesn't mean it costs nothing to implement. The web benefits from the largesse of rich patrons, any alternatives would need to either find a patron or find some business model that let it grow in quiet corners until it was strong enough to be fully competitive.

omeze 4y ago

do you have an opinion on which direction is more likely? naively I'd say 2 would be better since it'd require less language-specific toolchain work for a better devexp for the end developer.

josephg 4y ago
Option 1 - Webassembly without a built-in garbage collector - exists today. You can compile Go or C# to WASM today, and it will output a WASM module with an embedded garbage collector. There's a draft proposal to add a built in garbage collector (option 2) to WASM. I have no idea what the current status is - maybe someone involved can chime in. I suspect some version of the WASM GC spec will land eventually. When it does, languages like Go, C# and Java should start to become competitive with javascript as frontend web languages. https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc
- aidenn0 4y ago
  How does it find the GC roots on the stack?
  - flohofwoe 4y ago
    AFAIK garbage collected 'objects' are completely separate from regular WASM heap allocations and tracked directly by the WASM VM (I may be wrong though, but details are here: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...)
    - aidenn0 4y ago
      I meant in e.g. the C# runtime...
- brabel 4y ago
  WASM GC is already in the implementation phase[1], which means, IIUC that it's a matter of time for it to make into the official standard (i.e. the spec itself is mostly done now)... the implementations are behind a feature flag in Chromium[2] and Firefox seems to be far into making it available, see the current list of WASM-related issues they're working on[3]: [1] https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals [2] https://chromestatus.com/feature/6062715726462976 https://chromestatus.com/feature/6062715726462976 [3] https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=JavaScript%3A%20WebAssembly&bug_status=__open__ https://bugzilla.mozilla.org/buglist.cgi?product=Core&compon...
deleted 4y ago
[deleted]

kaba0 4y ago

> The benefit of (1) is that it makes webassembly virtual machines simpler and safer Why would that be safer at all?

josephg 4y ago
It lowers the surface area for bugs (and thus vulnerabilities). WASM is gloriously simple right now. Adding a garbage collector dramatically increases the security surface area.
- kaba0 4y ago
  I do believe that the tradeoff is well worth it though. We can write very high quality software (think of JVM, V8, etc) when the incentives are different than the 163748th CRUD app. Otherwise we could just as well use a trivial brainfuck interpreter as target, that won’t have a vulnerability ever.

still_grokking 4y ago

This comment repeats a fundamental error and misunderstanding: WASM is (currently) not able to be a compilation target for an efficient GC implementation. It lacks features needed to be able to implement GCs reasonably, like memory barriers. So 1. is out of scope if you don't want a bloated super slow language runtime running on top of WASM (like e.g. Blazor). The issue is known since the very beginning. Nobody in charge is willing to solve it. Also 2. is not happening, even it was discussed also since many years. But that makes actually "sense" form the WASM people's perspective: WASM was never meant to by concurrency to JS in the browser! WASM is merely a performance booster for where JS sucks (like numerical code). That WASM will allow to use other languages (and their ecosystems) in the browser is just a day dream of some. The companies behind "the web platform" won't give up on their billions worth of investments into the JS ecosystem. So no, GC languages other than JS won't ever run "natively" on the browser in a meaningful way. WASM is crippled on purpose in this regard, and as long as the current stack holders continue to control "the web platform" this won't change.

mike_hearn 4y ago
> WASM is (currently) not able to be a compilation target for an efficient GC implementation. Even if it was, there are other problems that mean the dream of being able to use alternative languages and runtimes on the web is far off, if it even ever happens at all. As a hobby I'm writing a design doc for an alternative non-web system design. It enumerates some of those problems and proposes solutions, along with other dissatisfying aspects of the web (e.g. the unimplementably large size of the web specs). https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI4J5AbxVWKEeYr6hscT8/edit?usp=sharing https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI... It's designed to be a very lightweight set of layered specs and projects that are way cheaper to implement than HTML5, can be developed and deployed incrementally whilst providing value from the start and which places other runtimes on a level playing field vs HTML. It also addresses many of the details you need to tackle for any serious web-like system such as transiency, sandboxing, tabbed WM, cache privacy, portability and hyperlinking. I sent it to Ian Hixson who found it interesting, but of course the sticking point is funding models. Being way cheaper to implement than the web doesn't mean it costs nothing to implement. The web benefits from the largesse of rich patrons, any alternatives would need to either find a patron or find some business model that let it grow in quiet corners until it was strong enough to be fully competitive.