4 ms·
It's less so opinionated and more so that WASM GC spec is just bad and too rudimentary to be anywhere near enough for more sophisticated GC implementations foun
by neonsunset 2y ago
It's less so opinionated and more so that WASM GC spec is just bad and too rudimentary to be anywhere near enough for more sophisticated GC implementations found in JVM and .NET.
- gwbas1c 2y agoIt's been awhile since I skimmed the proposal. What I remember is that it was "just enough" to be compatible with Javascript; but didn't have the hooks that C# needs. (I don't remember any mentions about the JVM.) I remember that the C# WASM team wanted callbacks for destructors and type metadata. Personally, having spent > 20 years working in C#, destructors is a smell of a bigger problem; and really only useful for debugging resource leaks. I'd rather turn them off in the WASM apps that I'm working on. Type metadata is another thing that I think could be handled within the C# runtime: Much like IntPtr is used to encapsulate native pointers, and it can be encapsulated in a struct for type safety when working with native code, there can be a struct type used for interacting with non-C# WASM managed objects that doesn't contain type metadata.
- neonsunset 2y agoHere's the issue which gives an overview of the problems: https://github.com/WebAssembly/gc/issues/77 https://github.com/WebAssembly/gc/issues/77 Further discussion can be found here: https://github.com/dotnet/runtime/issues/94420 https://github.com/dotnet/runtime/issues/94420 Turning off destructors will not help even a little because the biggest pain points are support for byref pointers and insufficient degree of control over object memory layout.