Links to discussions about why WASM GC in its current state is not suitable for .NET: https://github.com/WebAssembly/gc/issues/77
replyWhat should be improved: https://github.com/dotnet/runtime/issues/94420
I'm not familiar with the current spec and those posts are from 6/3 years ago, respectively. Do you happen to know if anything has changed since?
reply[dead]
replyThis is another good example that not all GCs are born alike, even though its is common to place them on the same basket.
replyWASM GC is a MVP, only usable by languages whose GC requirements overlap with JavaScript's GC.
Java has it easier than either Go or C#, because the Java and JVM specification is actually silent on how GC should be implemented, hence why there are so many implementations to chose from across JVMs.
Outside the browser there is hardly any value, just use JVM or CLR directly.
> Native interop with JS objects on the JS GC heap isn't supported as well.
replyIsn't that what the i31 type is for, that extra bit is a tag for...something, native GC'd object perhaps? Not so clear on that myself as Java's object model (minus synchronized) slots in perfectly so my Java 1.0 -> wasm compiler doesn't need it but that's my limited understanding of what it's for.
I'm not sure what they mean by "native" here but (ref extern) is for host references, JS or otherwise. The i31 type is for "immediate" values, things that can fit in 31 bits and thus don't need to be allocated on the heap.
reply