3 ms·

Is anyone using WASM with GC languages? I think they added support for that in the last WASM, has that changed the landscape of available languages?

by andai 8mo ago

apitman 8mo ago
Some exist at least: https://spritely.institute/hoot/ https://spritely.institute/hoot/
spankalee 8mo ago
I'm writing a new Wasm GC language because I'm so unsatisfied with the current options. I'm three months in, and so for it's mostly good. WASM takes care of all the GC bits, but in turn you have to use its ref, struct, and array types for everything. Making vtables is straight forward. Fat pointers for interfaces require an object though, since you can't do your own pointer layout. In web contexts GC should be great because browser GCs can work across DOM, JS, and WASM, so you can hold a reference to a node that you get via JS, and if you remove the node from the DOM and discard the reference, it'll be collected just like in JS. The big downside is data transfer over the Wasm boundary requires a lot more copying with GC. Byte arrays like (array i8) are completely opaque to the outside, so you need to vend individual byte access functions to read data. On the WASI side, it only lowers to linear memory, so you need to allocate some from scratch space, then copy into GC structs and arrays. Strings are doubly awful because of this because you also have to deal with encoding. GC also doesn't support multi-threading yet. Some of this is supposed to be fixed by things like https://github.com/WebAssembly/design/issues/1569 https://github.com/WebAssembly/design/issues/1569 and WASI lowering to GC types. stringref would have been great, but that appears to be dead for now. So I'm on board and optimistic these things will get fixed, but GC is still a bit of a second-class citizen for now.
- James_K 8mo ago
  If you are interested in multi-byte access to GCed arrays, something similar can already be accomplished. You can hold the array data in Wasm linear memory, then have an object that wraps a pointer to it, and using JS code, associate a finalizer with that object that frees the related section of linear memory. It's essentially how FFI memory is handled in most native GCed languages.
  - spankalee 8mo ago
    I considered that, but it requires more pointer indirection and I'm supporting WASI as a first class target, so won't always have access to JS finalizers. I'm going with copying as simpler for now, praying that multi-byte access lands by the time my language is viable.
pjmlp 8mo ago
Nope, if I want GC on the browser, I already have JS and TS (as JS linter). Outside the browser, GC available on JVM and CLR runtimes are much more advanced than WASM GC will ever be.
gavinray 8mo ago
.NET's Blazor client-side framework is C# WASM.
skocznymroczny 8mo ago
I think most GC languages that compile to WASM don't use the built-in GC support in WASM, but just compile the GC to WASM also. Languages like Go, Java, C# have support for WASM.

Is anyone using WASM with GC languages? I think they added support for that in the last WASM, has that changed the landscape of available languages?

by andai 8mo ago

Is anyone using WASM with GC languages? I think they added support for that in the last WASM, has that changed the landscape of available languages?

apitman 8mo ago

Some exist at least: https://spritely.institute/hoot/ https://spritely.institute/hoot/

spankalee 8mo ago

I'm writing a new Wasm GC language because I'm so unsatisfied with the current options. I'm three months in, and so for it's mostly good. WASM takes care of all the GC bits, but in turn you have to use its ref, struct, and array types for everything. Making vtables is straight forward. Fat pointers for interfaces require an object though, since you can't do your own pointer layout. In web contexts GC should be great because browser GCs can work across DOM, JS, and WASM, so you can hold a reference to a node that you get via JS, and if you remove the node from the DOM and discard the reference, it'll be collected just like in JS. The big downside is data transfer over the Wasm boundary requires a lot more copying with GC. Byte arrays like (array i8) are completely opaque to the outside, so you need to vend individual byte access functions to read data. On the WASI side, it only lowers to linear memory, so you need to allocate some from scratch space, then copy into GC structs and arrays. Strings are doubly awful because of this because you also have to deal with encoding. GC also doesn't support multi-threading yet. Some of this is supposed to be fixed by things like https://github.com/WebAssembly/design/issues/1569 https://github.com/WebAssembly/design/issues/1569 and WASI lowering to GC types. stringref would have been great, but that appears to be dead for now. So I'm on board and optimistic these things will get fixed, but GC is still a bit of a second-class citizen for now.

James_K 8mo ago
If you are interested in multi-byte access to GCed arrays, something similar can already be accomplished. You can hold the array data in Wasm linear memory, then have an object that wraps a pointer to it, and using JS code, associate a finalizer with that object that frees the related section of linear memory. It's essentially how FFI memory is handled in most native GCed languages.
- spankalee 8mo ago
  I considered that, but it requires more pointer indirection and I'm supporting WASI as a first class target, so won't always have access to JS finalizers. I'm going with copying as simpler for now, praying that multi-byte access lands by the time my language is viable.

pjmlp 8mo ago

Nope, if I want GC on the browser, I already have JS and TS (as JS linter). Outside the browser, GC available on JVM and CLR runtimes are much more advanced than WASM GC will ever be.

gavinray 8mo ago

.NET's Blazor client-side framework is C# WASM.

skocznymroczny 8mo ago

I think most GC languages that compile to WASM don't use the built-in GC support in WASM, but just compile the GC to WASM also. Languages like Go, Java, C# have support for WASM.