rossberg
commented
4 years ago
- Object layout [...] The type system of the current proposal doesn't seem to be able to support this layout, i.e. a header followed by array data. Also, .NET supports arrays of structs, i.e. an array of {ref,non-ref} would look like in memory: [ref, non-ref, ref, non-ref, etc.].
This form of nesting aggregates is supported (and I agree essential) as a Post-MVP feature. We cut it from the MVP because it can always be replaced with an indirection, so isn't strictly required for functional completeness. That decision could be reversed, of course, but it is tricky keeping the MVP small.
- Interior pointers In .NET, its quite common to have pointers into the middle of objects (arrays), and pointers to one past the end of an array. anyref doesn't seem to be able to support this.
Interior references are part of nested aggregates extension described above, so equally Post-MVP atm. They will be a distinct type from regular references (which can be converted into them). The reason is that this allows engines to represent them differently, e.g., as fat pointers. In past discussions with .NET folks they believed this would probably be good enough for .NET, because inner pointers only arise in specific contexts, but this requires further investigation.
- Interop with C/C++ code The .net runtimes are written in C/C++ and assume that object references are normal C pointers which point to linear memory, and objects can be accessed from C code as a pointers to C structs.
Yes, this is a known limitation. It is unlikely that much can be done about it directly. However, interface types may be able to emulate this interop.
- Finalization
- Weak references
These are tough ones, and we don't have a good idea yet how to support the myriads of different finalisation semantics out there without creating a zoo. Very likely Post-post-MVP, but suggestions are welcome.
- Non web runtimes Non-web runtimes would need to add a GC implementation, since GC is such a core feature that it probably cannot be treated as an optional feature like SIMD.
It is a stated goal that GC remains an optional feature. We have been very careful to design this and other features such that there are no unwanted dependencies on the presence of GC.
- LLVM support The new types/type constructs don't exist in LLVM, not clear how they can be added.
True, but that's a tool chain problem that needs solving and that is fundamentally unavoidable.
Horcrux7
aardappel
tlively
vargaz
aykevl
pmatos
bashor
asb
malekbr
I was asked to add some notes based on the needs of Microsoft .NET implementations wrt GC in WebAssembly.
The type system of the current proposal doesn't seem to be able to support this layout, i.e. a header followed by array data. Also, .NET supports arrays of structs, i.e. an array of {ref,non-ref} would look like in memory: [ref, non-ref, ref, non-ref, etc.].
In general, it seems very difficult to model all possible object layouts used by GCd languages.
Interior pointers In .NET, its quite common to have pointers into the middle of objects (arrays), and pointers to one past the end of an array.
anyrefdoesn't seem to be able to support this.Interop with C/C++ code The .net runtimes are written in C/C++ and assume that object references are normal C pointers which point to linear memory, and objects can be accessed from C code as a pointers to C structs. The current proposal places allocated objects outside linear memory and adds new accessors to read/write their contents. To allow manipulation of these objects from C code would require extensions to the C compilers.
Finalization The .net runtime needs to be notified somehow when an object with a finalizer dies.
Weak references .net supports multiple kinds of weak references which might not be supported by the underlying JS GC.
Non web runtimes Non-web runtimes would need to add a GC implementation, since GC is such a core feature that it probably cannot be treated as an optional feature like SIMD.
LLVM support The new types/type constructs don't exist in LLVM, not clear how they can be added.