3 ms·

Sorry to be ignorant, but I have a couple questions about Wasm: - Will the Wasm GC pave the way to having native object references to JS objects/classes (seein

Sorry to be ignorant, but I have a couple questions about Wasm: - Will the Wasm GC pave the way to having native object references to JS objects/classes (seeing how its the same GC as used by JS)? - Is it possible to do lightweigt interop between a high level language using Wasm GC (such as Java), with a low-level one (such as C++) that doesn't use it? If, so, how? Imo the biggest shortcoming of Wasm is the incredibly awkward way in which it integrates into the browser

whizzter 2y ago
Like the article says, you can have _opaque_ references. It's really a small step forward but does address a major pain point. So for your first question. Yes you can hold a reference, so the major benefit is that dead objects via things like memory cycles aren't an issue any more (previously connecting objects between WASM and JS worlds needed manual references that outside of something like C++ RAII would be brittle). For the second part, it would depend on the compiler but since Java/C++ would both live in a WASM world they should be possible to combine fairly painlessly (given a sane way to declare linked functions that are named properly), I'd put it's interoperability issues at the same level as PInvoke from C#.
- torginus 2y ago
  PInvoke is awesome. If you use MSVC for C++ it can do stuff like SEH/stack debugging that goes from .NET frames to C++ and back.
  - pjmlp 2y ago
    Even better, if Windows is the only deployment target, throw away P/Invoke, use C++/CLI and there is no need to guess how to get P/Invoke attributes exactly correct for each API call.
flohofwoe 2y ago
> Will the Wasm GC pave the way to having native object references to JS objects/classes AFAIK that was already possible via 'WASM reference types': https://caniuse.com/wasm-reference-types https://caniuse.com/wasm-reference-types Seeing that this is not yet used by Emscripten JS shims I wonder if there are downsides which prevent its use for something like WebGL objects, or whether just nobody got around yet rewriting the Emscripten shims to externrefs. PS: probably not worth the effort (see last comment: https://github.com/emscripten-core/emscripten/issues/20021 https://github.com/emscripten-core/emscripten/issues/20021)

whizzter 2y ago

Like the article says, you can have _opaque_ references. It's really a small step forward but does address a major pain point. So for your first question. Yes you can hold a reference, so the major benefit is that dead objects via things like memory cycles aren't an issue any more (previously connecting objects between WASM and JS worlds needed manual references that outside of something like C++ RAII would be brittle). For the second part, it would depend on the compiler but since Java/C++ would both live in a WASM world they should be possible to combine fairly painlessly (given a sane way to declare linked functions that are named properly), I'd put it's interoperability issues at the same level as PInvoke from C#.

torginus 2y ago
PInvoke is awesome. If you use MSVC for C++ it can do stuff like SEH/stack debugging that goes from .NET frames to C++ and back.
- pjmlp 2y ago
  Even better, if Windows is the only deployment target, throw away P/Invoke, use C++/CLI and there is no need to guess how to get P/Invoke attributes exactly correct for each API call.

flohofwoe 2y ago

> Will the Wasm GC pave the way to having native object references to JS objects/classes AFAIK that was already possible via 'WASM reference types': https://caniuse.com/wasm-reference-types https://caniuse.com/wasm-reference-types Seeing that this is not yet used by Emscripten JS shims I wonder if there are downsides which prevent its use for something like WebGL objects, or whether just nobody got around yet rewriting the Emscripten shims to externrefs. PS: probably not worth the effort (see last comment: https://github.com/emscripten-core/emscripten/issues/20021 https://github.com/emscripten-core/emscripten/issues/20021)