4 ms·

You've already got 2 co-operating languages - JS and whatever is compiler to WASM.

amelius 8y ago
True, but once you're using WASM, you probably don't need to hold references to JS objects that point back to the objects created in WASM. We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now?
- TomMarius 8y ago
  Because that's not safe. It's only as safe as the Python binding is, which is not good enough.
  - amelius 8y ago
    Define "safe". Are you talking about security or correctness, or both, and please elaborate.
    - TomMarius 8y ago
      The point of WASM is the ability to safely run any untrusted code in a performant way, that includes seamless interfacing with other modules. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
      - amelius 8y ago
        I'm sure that if you can make WASM secure without the GC part, then you can create a safe interface. Yes, it may leak memory (remember, so can a GCed program that forgets to unreference objects), but that's just something you have to deal with when programming at a low level; and languages built on top of WASM can make that a non-issue, actually. Let's keep WASM simple. It's probably the best thing one could do in view of security.
        TomMarius 8y ago
        Can you elaborate on how two WASM modules each with its own GC could safely interface without unnecessary overhead? Why would we want to have this overhead in the first place? It may not be that bad with 2 modules, but you might easily have 20 or (way) more.
        de_watcher 8y ago
        I've got multiple specialized GCs within one module, and they're doing fine. Trying to shoehorn everything into one model isn't something that should have 'asm' in its name.
        TomMarius 8y ago
        OK, but could you share the specifics? I'd like to understand. Emphasis on combination of safety (primary) and performance (secondary) - remember that any number of completely unrelated, untrusted, maybe buggy and potentially even malicious modules might be combined. They're being very careful about not forcing languages into one model, BTW.
- rkangel 8y ago
  > We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now? Because C doesn't need garbage collection, it uses 'manual' memory management. This scenario is exactly analogous to the WASM-JS world that exists now (WASM is manual, and JS is GC). The goal here is to have a GC that's usable in WASM, and WASM is going to be interoperating a lot with JS for many applications, so it needs to cope with that. A better analogy in this case would be IronPython which is Python built on the .NET framework rather than C. In that case, the Python GC is the .NET GC, so that objects can be passed back and forth 'between worlds'.

True, but once you're using WASM, you probably don't need to hold references to JS objects that point back to the objects created in WASM. We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now?

TomMarius 8y ago
Because that's not safe. It's only as safe as the Python binding is, which is not good enough.
- amelius 8y ago
  Define "safe". Are you talking about security or correctness, or both, and please elaborate.
  - TomMarius 8y ago
    The point of WASM is the ability to safely run any untrusted code in a performant way, that includes seamless interfacing with other modules. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
    - amelius 8y ago
      I'm sure that if you can make WASM secure without the GC part, then you can create a safe interface. Yes, it may leak memory (remember, so can a GCed program that forgets to unreference objects), but that's just something you have to deal with when programming at a low level; and languages built on top of WASM can make that a non-issue, actually. Let's keep WASM simple. It's probably the best thing one could do in view of security.
      - TomMarius 8y ago
        Can you elaborate on how two WASM modules each with its own GC could safely interface without unnecessary overhead? Why would we want to have this overhead in the first place? It may not be that bad with 2 modules, but you might easily have 20 or (way) more.
        de_watcher 8y ago
        I've got multiple specialized GCs within one module, and they're doing fine. Trying to shoehorn everything into one model isn't something that should have 'asm' in its name.
        TomMarius 8y ago
        OK, but could you share the specifics? I'd like to understand. Emphasis on combination of safety (primary) and performance (secondary) - remember that any number of completely unrelated, untrusted, maybe buggy and potentially even malicious modules might be combined. They're being very careful about not forcing languages into one model, BTW.
rkangel 8y ago
> We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now? Because C doesn't need garbage collection, it uses 'manual' memory management. This scenario is exactly analogous to the WASM-JS world that exists now (WASM is manual, and JS is GC). The goal here is to have a GC that's usable in WASM, and WASM is going to be interoperating a lot with JS for many applications, so it needs to cope with that. A better analogy in this case would be IronPython which is Python built on the .NET framework rather than C. In that case, the Python GC is the .NET GC, so that objects can be passed back and forth 'between worlds'.