Tame MVP to support hardware garbage collectors

[dumblob]

The comment #36 (comment) literally pushed me to open this issue.

I strongly believe, that WebAssembly will stay with us for quite long as the most widespread "world-wide interoperable assembly" and I think due to RISC-V and many other initiatives, hardware will get yet easier to design and cheaper to produce. A hardware garbage collector will then most probably appear like an avalanche as it's quite simple to implement it additionally to existing chips (even huge ones like AMD Threadripper).

Let me therefore refer to findings in the paper https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-hwgc.pdf and ask for making WebAssembly GC MVP fully compatible (in terms of efficiency) with the hardware specifics and constraints outlined in the paper.

[rossberg]

Thanks for the link, I hadn't seen that paper. Hardware acceleration for GC is an exciting topic. If we can do anything to support a revival of this idea (anyone remembers Lisp machines?) then we should.

Fortunately, I believe that the GC proposal is abstract enough to be almost entirely agnostic towards the use of hardware acceleration -- that would remain an implementation detail of an engine. If you spot something in the MVP that would be in the way of that then we should discuss it.

That being said, the paper you link makes one rather problematic assumption that is not quite compatible with post-MVP features and the needs of some languages. Specifically, it requires every object to be strictly split into a reference and a non-reference part. This may work for OO and single inheritance, which, unfortunately, is all the paper considers, but not for less simplistic forms of type composition. For example, if you need to support something like array (struct {i32, anyref}) (as, e.g., Go or other languages) then the aforementioned splitting is not possible, or at least highly undesirable, because reordering/transposing the array would destroy locality and composable access (especially at higher array dimensions). Not sure if there is an obvious solution to avoiding expressive enough type descriptors in such cases.

[tlively]

Closing this because the initial suggestion has been addressed and this does not appear to be further actionable. If you have more to add, please reopen this or file a new issue.

[dumblob]

Thanks everyone!