3 ms·

Where can I find more information about managed data types in WebAssembly?

davexunit 3y ago
GC managed types? Wasm GC spec: https://webassembly.github.io/gc/core/index.html https://webassembly.github.io/gc/core/index.html Heap types in particular: https://webassembly.github.io/gc/core/syntax/types.html#heap-types https://webassembly.github.io/gc/core/syntax/types.html#heap... V8 blog post about GC: https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting
- singularity2001 3y ago
  now that it will be cheaper and more natural to pass data back and forth with JavaScript, are we likely to see Wasm/GC progressively occupying more space in web applications? is there any tracking issue to see when JavaScript will finally be able to read and write Wasm/GC objects? The last time I checked any such attempt would result in an error
  - davexunit 3y ago
    Part of Wasm's capability security model is that JS objects are opaque to Wasm and Wasm objects are opaque to JS. This is a good thing and it doesn't prevent interop. Everyone asks about DOM nodes, so let's use that as an example. In Wasm, you could import a function known locally as $documentGetElementById. The host (JS) could then instantiate the module and provide Document.prototype.getElementById.bind(document) as the implementation of that import. $documentGetElementById's return type would be (ref extern), an opaque reference to a heap object from the host that can now be freely passed around the Wasm module or back to the host. You could then import any other DOM functions that you need to inspect/manipulate these objects. On the flip side, if you have a Wasm object reference in JS, you need to call some exported Wasm function(s) to inspect/manipulate it.
    - singularity2001 3y ago
      How does it not prevent interop if JS can't even read or write the struct data provided by wasm? If they still require glue code hell, what's even the point?

GC managed types? Wasm GC spec: https://webassembly.github.io/gc/core/index.html https://webassembly.github.io/gc/core/index.html Heap types in particular: https://webassembly.github.io/gc/core/syntax/types.html#heap-types https://webassembly.github.io/gc/core/syntax/types.html#heap... V8 blog post about GC: https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting

singularity2001 3y ago
now that it will be cheaper and more natural to pass data back and forth with JavaScript, are we likely to see Wasm/GC progressively occupying more space in web applications? is there any tracking issue to see when JavaScript will finally be able to read and write Wasm/GC objects? The last time I checked any such attempt would result in an error
- davexunit 3y ago
  Part of Wasm's capability security model is that JS objects are opaque to Wasm and Wasm objects are opaque to JS. This is a good thing and it doesn't prevent interop. Everyone asks about DOM nodes, so let's use that as an example. In Wasm, you could import a function known locally as $documentGetElementById. The host (JS) could then instantiate the module and provide Document.prototype.getElementById.bind(document) as the implementation of that import. $documentGetElementById's return type would be (ref extern), an opaque reference to a heap object from the host that can now be freely passed around the Wasm module or back to the host. You could then import any other DOM functions that you need to inspect/manipulate these objects. On the flip side, if you have a Wasm object reference in JS, you need to call some exported Wasm function(s) to inspect/manipulate it.
  - singularity2001 3y ago
    How does it not prevent interop if JS can't even read or write the struct data provided by wasm? If they still require glue code hell, what's even the point?