Gc: Agenda for subgroup meeting - June 2, 2020

[binji]

We will have our first subgroup meeting on June 2, 2020 at 9am PDT (6pm CET). As with other Wasm meetings, we'll host this on zoom. If you would like to attend, please fill out this form.

Please respond to this issue with topics for the agenda.

[RossTate]

Here's an idea for a discussion topic, but I'd want to know if people are interested. I was chatting with @steveblackburn about the various challenges and constraints with helping linear-memory memory managers cooperate (asynchronously) with host memory managers. We had some ideas, and got a good sense of what the real problematic cases look like, but it would help to get a sense from y'all of what the various patterns look like concretely rather than just abstractly. Unfortunately, Steve won't be able to make the meeting due to the timezone differences (he's in Australia), but I'll do my best to collect notes for him. Does that seem like a useful topic?

[titzer]

This is a useful topic. I'm in the same time zone as Steve. His office is 20 feet away. Office....ah, those were the days, two months ago....

Yes, I would like to discuss this issue.

[jakobkummerow]

From a timeline/priorities point of view, I would appreciate it if this subgroup's initial focus was on finding consensus on a first version ("MVP") of GC support for Wasm, or in other words: what needs to happen so that https://github.com/WebAssembly/gc/blob/master/proposals/gc/MVP.md can move along the phases process and become a standard:

• do we simply need more discussions / explanations to address doubts and concerns?
• do we need more clarity / elaboration on plans and visions for post-MVP additions? Can we, maybe, find agreement on a fairly minimal MVP if we at the same time agree on a specific "to-do" list for future additions to seriously look into? Would items on such a list already need to include rough outlines on how they will interface/interact with the foundations laid in the MVP?
• do we need to cut scope, or to expand scope, or both, to ensure that the "MVP" feature set fits that name?
• do we need any fundamental changes in the design of the overall approach, or of individual features?
• as a variant of the above, do we need to spend some time exploring alternatives, even if we expect to eventually rule them out as "not better" (and document the reasons), just so we're sure we haven't overlooked any compelling alternatives? (To what extent would this be different from what's already happened since this proposal was created ~3 years ago?)
• how do we answer the several open questions, including (in no particular order):
  
  
  
  • include runtime types (in their current form, or not at all, or differently)?
  
  
  • include i31ref (now, or later, or never)? As a generalization of this, what are the principles for finding the right balance between (1) Wasm-side expressiveness and flexibility of managed objects, (2) Wasm-side ease of use and conciseness, (3) implementation simplicity, (4) freedom of implementation choices, and (5) implementation optimization potential?
  
  
  • structural or nominal typing or both? (e.g. structural semantics for static types and nominal semantics for runtime types)
  
  
  • probably a dozen other open questions that I'll skip here because this post is already too long
  
  

In this framing, I'm not sure how y'all are thinking about the topic @RossTate suggested above. Do you see it as a fundamental question that must be answered before we can agree to move ahead with a non-linear-memory GC proposal? If so, by all means, let's have that discussion and get that clarity one way or the other. Or do you see it as an interesting beyond-MVP exploration? If so, I would humbly suggest to postpone it until after we've brought the MVP closer to finalization.

As a specific first step, I would suggest that any relevant conversations that may have happened in smaller rounds report their outcomes to the wider group. That could happen in the Zoom meeting, or in the form of PRs and issues filed at any time.

Maybe it would also be useful to collectively assemble a (more authoritative than my sketch above) list of things that will need to be addressed/decided in order to make progress on the/a proposal, so that we know where we stand?

[RossTate]

That's a reasonable request. There were a few reasons I suggested the above topic:

1. It's not contentious (I believe), so given that this is our first subgroup meeting I thought it might set up a better group dynamic.
2. One of the requests for the charter was to incorporate consideration of linear-memory garbage collection, so this sets up an inclusive environment for those concerns.
3. Depending on what the details of the problem looks like, one potential solution involves some variant of finalizers, and it would be useful to know if such a feature should be considered MVP.
4. There are some ongoing discussions that affect the bigger issues above, such as the ones in Type Imports, so it would be useful to have more progress on those first.

That last item connects to your suggestion of listing items, which I think is a good suggestion. Were you suggesting doing that here or at the meeting?

[jakobkummerow]

Were you suggesting doing that here or at the meeting?

I was thinking it might fit in well as a meeting agenda item, but we can certainly also do it here if folks prefer. Or maybe we don't need a new list, and this issue tracker should just be _the_ list? 54 open issues, many of which haven't been updated in a year or more, could do with some curating then though.

[binji]

I agree with @jakobkummerow that our first meeting should focus on getting the subgroup up-to-speed with the disparate developments in this space. So I think for the first meeting we should start with a quick round of introductions, then status updates organized by topic.

As for the topics, I think we should list them here and ask one person to present an overview to the group about that topic. We don't have time to cover these comprehensively. But perhaps we could do 5-10 minutes each, starting with summary, pointers to the most recent information, followed by any open questions, and next steps/future work. I imagine we can pretty easily fill up the full hour this way.

Here is a quick list of topics that we may want to cover, feel free to suggest more:

• Status of the current proposal document; there were some recent changes
• Status of the soil-initiative proposal
• Status of various linear memory proposals
  
  
  
  • GC in linear memory
  
  
  • Implementing GC via stack walking primitives
  
  
• Status on various GC prototypes (v8, spidermonkey, wabt)
• Status from various languages/runtimes:
  
  
  
  • .NET
  
  
  • Go
  
  
  • Kotlin
  
  
  • Others?
  
  
• Status of upstream proposals
  
  
  
  • typed function references
  
  
  • type imports
  
  

What does everyone think?

[binji]

54 open issues, many of which haven't been updated in a year or more, could do with some curating then though.

Good point, I'll do some triage today.

[Horcrux7]

Status from various languages/runtimes:

• .NET
• Go
• Kotlin
• Others?

FYI: Java (JWebAssembly project) use currently a polyfill via JavaScript or the SpiderMonkey prototype. If a binary release of WABT with GC is available, I will switch fully to GC. Just my two cents.

[rossberg]

I can present proposal statuses. Should probably start with the upstream ones, since that's were most of the spec-side action has moved.

[binji]

Thanks, @rossberg. I assume you won't cover the various other GC alternative proposals, right?

Should we try to do status of those too in this meeting? @RossTate @aardappel What do you think?

@jakobkummerow @eqrion An update on the v8/SM prototypes would be useful too, would you be able to present?

[RossTate]

I'm happy to put something together, but would appreciate some more guidance on what y'all would like. Maybe a quick video chat would be good to hash out what you think would work well?

[binji]

@RossTate My thought here is to try to make sure everyone in the group knows what is currently being worked on, since there's a lot going on and it's hard to keep up with all of the discussions. So I was hoping that you could do a short summary of the discussions/designs you've been involved with. Maybe that's too much to cram into one meeting though? But yeah, let's chat offline.

[aardappel]

@binji I'd be happy to summarize https://github.com/WebAssembly/gc/issues/78 .. I can keep it as short as needed :)

[fgmccabe]

In the spirit of facilitating a smooth process over the lifetime of this effort, I offer the following thoughts on process:

• Identify the stakeholders.

When raising a topic, or expressing an opinion, it is useful to be able to identify the stakeholders you are representing. E.g., we need nominal types in order to implement Scheme records (not).

• Criteria first

Identify criteria before technical solutions. This allows given ideas to be measured against the criteria; as opposed to simple argumentation on the different features of the proposed solution.
E.g., before arguing about how memory structures might make interoperability with JS code impossible, establish that support for multiple GC languages is important; then one can measure the effect on that of memory structures (if any)

• Are you ‘RoadKill’?

Being roadkill for an idea means that you are sufficiently certain of your case that you are willing to be ‘run over’ by the rest of the group if they disagree with you.

Signalling whether you are roadkill or not can be very helpful to other members of the group. In the given heat of the moment, it can be difficult for others to truly discern your intentions.

• Put up or shut up.

The most effective way to get agreement for a particular idea is to frame it in terms that amount to a ‘git commit’ to an eventual specification.
For example, instead of complaining about arrays in complex structures, frame your input as a specific modification of a document that has the effect of adding your input. This is _after_ establishing criteria and stakeholders ...

[binji]

Notes from today's meeting are here: https://github.com/WebAssembly/meetings/pull/571. Please update them as needed.