Agenda for subgroup meeting - October 6, 2020

[binji]

The next subgroup meeting is October 6, 2020 at 9am PDT (6pm CET). As with other Wasm meetings, we'll host this on zoom.

No registration required if you attended a previous meeting. Fill out the form here if it's your first time: https://forms.gle/JehrAB4gWbtHjybt9.

Please respond to this issue with topics for the agenda.

Agenda:

None yet.

[RossTate]

I think we should discuss #137. It follows on this week's conversation, but with a more focused topic, which will help structure discussion. It's also pressing because my understanding is that neither tooling nor engines have implemented the difficult aspects of rtt.canon, so a decision here could save substantial work. 30 minutes?

[binji]

I think sounds like a good topic. We haven't seen many others present topics in the last few sessions though, so if anyone does need >30 minutes for a topic, I'd like to give them precedence.

BTW, I'm going to be on vacation for the next few weeks, and I've asked @tlively to run the next meeting.

[RossTate]

That sounds like a good policy.

[rossberg]

With another alpha release lurking, I have been rather busy, so I apologise for the lack of engagement in recent discussions. I will try to put together a presentation clarifying some of the design constraints we face and some of the unfortunate confusions and conflations in recent discussions, as they relate to structural/nominal types as well as RTTs. That could easily take up a full hour with discussion. I can try to have something ready for next week, but happy to have more time and give precedence to some other topic.

[RossTate]

@rossberg Would you be able to bring up these constraints on the forum before such a presentation?

[conrad-watt]

The current (argumentation) logjam seems to me to be primarily about a difference in values and expectations, rather than being caused by misunderstandings.

There are two potential areas of misunderstanding that I see:

1. (cf. Permanent Slow Casting #120) is there a structural subtyping approach for castless arrays/this (e.g. bounded quantification with kernel-fun restrictions)?
2. is there a compelling use of GC types that makes a centralising top-level (for type names/subtyping) undesirable?

It might be that the answer to (1) is "not in general but some common cases can be handled" and (2) is "nothing specific but we want to avoid mandating it as a more abstract design principle" - in which case we're back to arguing over values. If there are more specific/satisfying answers, it would be good to get those aired, and I'd rather @rossberg take as long as necessary to make prepare the strongest possible presentation (whether in a GH issue or in an upcoming meeting).

I am concerned that we're going to get into a long debate that doesn't go anywhere because genuine differences in value judgements will be labelled as misunderstandings on both sides.

[RossTate]

@conrad-watt I am not opposed to @rossberg giving a presentation, but I want the in-meeting discussion to be productive, and that requires a prepared/informed audience. Ahead-of-time discussion of the design constraints and apparent unfortunate misconceptions seems to be the best means for such preparation.

As for (1), a perfectly reasonable decision the group can make is that we will commit to never eliminating certain classes of superfluous casts. The best way to make progress is for @rossberg to clarify which classes he will not eliminate even in any Post-MVP (giving evidence that the other classes can be eliminated), and then for the group to examine and discuss the consequences. I don't think a presentation is required for that. A clear statement of "The Post-MVP will not eliminate superfluous Java array-access casts" in #138 would be one step forward.

[conrad-watt]

@conrad-watt I am not opposed to @rossberg giving a presentation, but I want the in-meeting discussion to be productive, and that requires a prepared/informed audience. Ahead-of-time discussion of the design constraints and apparent unfortunate misconceptions seems to be the best means for such preparation.

I think I didn't make my point clearly. I was trying to say that @rossberg should probably not make a presentation in the coming meeting if he feels that more prep time would be helpful.

EDIT: that being said I hope that the time allotted for #137 can be used productively, because I don't think it stands on its own as a proposal, but only as a discussion point for drawing attention to #119.

[RossTate]

Ah, yes, agreed (on both points).

[RossTate]

For a second topic, it would be useful to have a discussion on what our thoughts are on superfluous casts. One concrete data point we have is that #120 suggests that superfluous casts can impose 48% on each array access of many reference types. Do we care?

[tlively]

Sounds like a good discussion to have, although I would want to back up a step and dive into the experiment you did to get that 48% measurement and discuss what other similar experiments we might want to perform. I think everyone cares about a 48% performance hit on common operations, so the work is in getting everyone on the same page that such a performance hit is likely under the current design.

[RossTate]

Sure. One way the discussion could go is to discuss experiments that could be done.

[fgmccabe]

I would like to bring up the requirements document. Specifically the one about supporting multiple GC memory spaces; and supporting multiple threads.

[RossTate]

Ah cool. That should take precedence.

[RossTate]

It occurs to me that the discussion on casts is rather requirements related, whereas the discussion on rtt.canon sounds potentially related to @rossberg's presentation. So I would suggest discussing casts tomorrow and deferring rtt.canon until later.

[tlively]

Ok, so if I understand correctly, our agenda for tomorrow will be 1) @fgmccabe leading a discussion of requirements, specifically the requirements around multiple GC memories and multiple threads, followed by 2) @RossTate leading a discussion about superfluous casts. Shall we allocate half an hour to each of those discussions?

Some time in the future, we would like to see @rossberg present design constraints and clarifications pertaining to the structural/nominal discussion as well as to see @RossTate continue our discussion from last time with the proposal in #137.

[fgmccabe]

Sounds good

[conrad-watt]

It occurs to me that the discussion on casts is rather requirements related, whereas the discussion on rtt.canon sounds potentially related to @rossberg's presentation. So I would suggest discussing casts tomorrow and deferring rtt.canon until later.

Not to suggest any changes to this agenda, but it's worth bearing in mind that all of these discussions are tightly related. Both the nominal and structural MVP will have the same casts, and therefore presumably similar performance, assuming enough memoization on the structural side, no matter what benchmark is used.

A more fundamental question is to what extent can a post-MVP structural system eliminate these casts, in comparison to a nominal system.
EDIT: and conversely, would any differences be acceptable performance-wise, which does require benchmark/requirements discussion.

It's fine to discuss good benchmarks and performance requirements, but we shouldn't expect them to allow us to make a decision without at least some post-MVP context.