Prototyping the SOIL initiative proposal: call for volunteers

[tlively]

There is a lot of community enthusiasm for the GC proposal right now. @dcodeIO is working on a prototype in Binaryen and @Brion has expressed interest in using that prototype to investigate JS compilation once it is ready.

I'm hoping we can harness some of that energy to work on prototyping the SOIL initiative proposal as well. Getting concrete experience with both of these designs is going to be hugely impactful for driving GC forward, no matter what the final GC proposal looks like.

If you're interested in helping out, I would be happy to help shepherd your prototyping work in Binaryen by discussing the implementation design with you and providing code review. I'm happy to discuss details with you here or on the WebAssembly Discord.

Please also let me know if you would be interested in investigating compiling your language to a prototype of the SOIL initiative proposal. We can work with @RossTate to figure out which features of the proposal your language will need and prioritize prototyping those features.

@dcodeIO, would the AssemblyScript project be interested in investigating the SOIL initiative proposal as well? If so, @torch2424, I'm sure you have a lot on your plate, but would this be something you would be interested in working on? @RossTate, do you know anyone who would be interested in working on an implementation of the proposal?

[conrad-watt]

If we're exploring/implementing one of the alternative proposals, something based on the Garbage Collection with Two Types sketch might require less brainpower/person-hours.

[dcodeIO]

I'm happy to help with Binaryen integration and general AssemblyScript guidance if there is interest in prototyping proposals involving the AS compiler. Anything present in Binaryen's C-API should be straight-forward to access and express, if not represented by a first-class language feature then as wat-like built-ins, annotated classes or custom syntax, likely living in its own branch.

Regarding what AssemblyScript as a project is most interested in, we'd love to see great interop between Wasm GC and the existing web platform, i.e. JavaScript [1] [2] [3]. Whatever proposal(s) addresses this concern can be certain of our attention, yet I see no reason that should hold anyone back from utilizing the AS compiler as a vehicle to prototype something that doesn't. The SOIL initiative proposal in particular looks like it neither addresses this nor shuts the door in this regard (please let me know if you think it does so I can get into arguments over the importance of compatibility on the open web), while garbage collection with two types is rather a surprise box (making it not less interesting to prototype to see if it can help).

TL;DR We are interested.

[tlively]

If someone is interested in prototyping the two-types solution (which would definitely be less work) in Binaryen, I would be happy to shepherd that work as well!

[bvibber]

I'm reading the SOIL proposal and it looks like the 'explicit' type relationships would allow for an optimized implementation to generate a NaN-boxing scheme for the universal value representation for my JS compiler design, while potentially falling back to heap boxing on a simpler engine. Interesting... will try a new sketch of that on top of this plan, see what it looks like...

[Well, at least it could pack full i32s on 64-bit platform. not sure about declaring f64s to be NaN-mutable?]

[bvibber]

Ok definitely not nan-boxing, but neatly letting the engine optimize "boxed" i32s into pointer tags magically sounds nice! But not being able to predict the performance of them is potentially not great. Overall though it's quite interesting. Most of my internals objects will be similiar under this design, but with some arrays combined into the structs for Strings and BigInts and such. Might be able to replace the type_id field with just using the RTT with a switch_case etc when needed for dispatch.

[torch2424]

@tlively Thanks for reaching out! 😄

I'm sure you have a lot on your plate

Definitely do haha! 😂 But totally down to help with this as I can, as I know it's going to be an important part of AS (And both my work and personal goals align with helping that!)

, but would this be something you would be interested in working on?

Totally! 😄 Though, I'm not entirely sure how I could help? You and @dcodeIO Let me know how/if I can! For now though, I'll let @dcodeIO drive this from the AS. As they have been following this much more closely than me 😄

---

Thanks! 😄 👍

[binji]

IMO, the first thing to do for either the SOIL or two-types proposals is to write up a first-pass binary and text format. It'll be hard to prototype anything without that.

[tlively]

Right, concretely what we need to happen is:

1. Work with proposal authors (@RossTate for the SOIL proposal or @taralx for the two-type proposal) to define complete instruction sets and text formats.

2. Implement parsing, printing, and interpretation for the types and instructions in Binaryen.

3. After that, @dcodeIO, @Brion, and anyone else can experiment with lowering source languages to the GC proposals.

So I am mostly looking for help with (2).

[ajklein]

Wouldn't you also want a runtime/engine interested in prototyping? It's unclear to me how much value would be gained from a toolchain alone.

[tlively]

That would certainly be useful, but I can't personally be as helpful with that as I can with Binaryen work. Even with just a debugging interpreter rather than an optimizing engine implementation, we would still be able to comparatively evaluate 1) how easy it is to emit GC code, 2) code size, and 3) how many casts or other performance-sensitive operations real-world code executes. Having a toolchain prototype also makes an engine prototype much more valuable, which makes it more likely that someone will work on one.

[MaxGraey]

Also I'm wondering is it possible polyfill GC on Binaryen side? So even without support GC on runtime engine we could use GC

[tlively]

@MaxGraey yes, in principle that would be possible, but it would be a large project on its own so it probably doesn't make sense to focus on for now.