5 ms·

Counter-intuitively, I feel as though GC results in better memory usage in this situation. Option 1: you rely on every single developer to be careful and make

• rubatuga 4y ago
  You can use reference counting memory management
  • dreamcompiler 4y ago
    Which is usually slower than a real gc and must punt to a real gc when you run out of counter space or have cycles.
• josephg 4y ago
  > 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...
• phplovesong 4y ago
  > Option 1: you rely on every single developer to be careful and make no memory-leaking mistakes. Nope. You use a language that dont have this problem, and handles memory safety within the compiler, just like what Rust does.
  • anonymoushn 4y ago
    Rust doesn't attempt to guarantee no memory leaks. Memory leaks are allowed in safe Rust.
    • tjoff 4y ago
      Sigh, no GC language guarantees no memory leaks either.
      • anonymoushn 4y ago
        So when someone comments "Or we could use a language that doesn't let you write memory leaks using the type system, like Java" then we can reply that that's not true about Java. But in this comment thread people only wrote that about Rust.
        • tjoff 4y ago
          Read the thread. The implication was that non-GC languages leads to memory leaks. Rust was then presented as an option that isn't worse than a GC language in that regard. Countering that with "Rust doesn't attempt to guarantee no memory leaks." is just silly...
          • anonymoushn 4y ago
            I read it. What problem is Rust claimed not to have, which C and C++ have? Which GC language makes no attempt to collect unreachable reference cycles, so that Rust is no worse?
  • kaba0 4y ago
• Aissen 4y ago
  My experience with Option 2, is that unless you're not memory-constrained, you'll always reach a point where you need to be GC-aware. Those objects you kept a reference two? GC can't collect them. This hot path that does allocations ? Better implement an object pool.