- Where: zoom.us
- When: September 26th, 4pm-5pm UTC (September 26th, 9am-10am Pacific Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Proposals and discussions
- Flexible vectors, announcement: add Tal Garfienkel as proposal co-champion [5 min]
- Exception handling: Potential discussions about the upcoming vote [15 min]
- Profiles discussion (rescheduled from 06/20/2023) [30 mins]
- Poll: Deterministic mode will be defined in the profiles proposal
- Poll: Phase 4 for Relaxed SIMD
- Closure
None
None
- Conrad Watt
- Deepti Gandluri
- Derek Schuff
- Andrew Brown
- Adam Klein
- Alex Crichton
- Alon Zakai
- Andreas Rossberg
- Antoni Bofarull
- Ashley Nelson
- Bailey Hayes
- Ben Visness
- Benjamin Titzer
- Chris Fallin
- Chris Woods
- Daniel Hillerström
- Nick Fitzgerald
- Francis McCabe
- Gordon Aplin
- Heejin Ahn
- Ilya Rezvov
- Jeff Charles
- Johnnie Birch
- Kartikey Rawat
- Luke Wagner
- Marat Duhkan
- Matthew Yacobucci
- Mike Smith
- Mingqui Sun
- Paolo Severini
- Petr Penzin
- Ryan Hunt
- Saul Cabrera
- Sam Clegg
- Sergey Rubanov
- Tal Garfinkel
- Usuario de Zoom
- Yuri Iozelli
- Yury Delendik
- Brendan Dahl
- Dan Gohman
- Richard Winterton
- Nick Ruff
- Dan Srebnik
- Keith Winstein
- Kartikey Rawat
HA presenting slides
This format was posted on GH about a month ago (WebAssembly/exception-handling#281) Would like to vote on whether to go this route in October meeting
FM: one of the merits of one of the precious proposals was that you could do analysis of an exnref outside a try context. That was useful for a CPS transform where exceptions are used outside of a try/catch. Is that possible now? I.e. decompose a caught exception without throwing it
HA: What do you mean by decomposing without throwing?
FM: If you’re doing a CPS transform, instead of using a throw instruction, you pass the exnref as an argument to another function, which can look at it. But you’re not throwing it.
CW: There are 2 different answers, if you really want to use exnref, you can try to rethrow it in the catch block immediately after the exception, the other option is to have the toolchain say that it doesn’t handle exnref directly, but needs a wrapper
FM: I’d be forced to use the first of those I think. (forced, but it wouldn’t be ideal)
BT: br_on_exn is syntactic sugar for what Conrad mentioned, we could consider that as a performance optimization, it's the same type of expressiveness, but better for performance
HA: in case it wasn’t clear, this try/catch block extracts the exception. In case there’s a tag match, we extract the values and the exnref (multivalue). So you get both on top of the stack at the end of the block. For catch_all we only push the exnref.
We did consider where try block doesn’t extract and use an additional br_on_exn like construct, but found that increased code size slightly with basically the same semantics.
DG: Some context: in the hybrid meeting last year, we discussed one of the prerequisites of moving relaxed SIMD to full phase 4 was a discussion about profiles. That lets you define language subsets with reduced functionality or restricted subsets, defined in a spec. Profiles have a spec and syntax, currently phase 1. I was hoping to use this time on some of the discussion that came up. A disagreement on how many profiles there should be, and some concerns about fragmentation. Also how do we add new profiles. It’s a slightly different paradigm than we have so far. Also since we took a dependency on an earlier stage proposal, and wanted to try to make sure we at least agree about the deterministic profile.
AR: clarifying that there are 2 separable things: the profiles proposal is mostly about the spec framework, a formal way to define them. But does not imply any specific use of that framework. We could have separate discussions about each profile we care about. This is about having the ability to express it. The deterministic profile is the first use case. But just defining a semantic framework doesn’t affect what the standard specifies, just mmakes it possible. So it doesn’t seem mlike a big risk as long as we’re clear that specific profiles need separate discussions. Because of that we can probably just move ahead with the profiles proposal if we wanted to get over the weird dependency situation. That’s what I would suggest. Maybe not today but maybe at the face to face meeting, move it forward (even to phase 4). Since its mostly editorial. I.e. do we want to have this ability at all in the spec, and given that we already wwant the deterministic profilek the answer seems yes.
DG: agree that we should move profiles forward. We discussed that folks just wanted soem time to look at it and figure out how they would try to incorporate it. But as AR said its really just the ability to have it in the spec. But the 2 points of disagreement came up when we discussed this before. I’m not sure we could poll to movie profiles forward today since it wasn’t on the agend, but no objection
RH: so the profiles proposal, just add infrastructure for defining profiles, but doesn’t define specific profiles? It’s just spec machinery?
AR: as written it suggests certain proposed profiles, but we can separate out. It mentions deterministic, but has open questions for certain others
RH: just thinking about the procedure. If you wanted to advance something like that. We might want a different process since it’s infrastructure
CW: we’d want to discuss how toolchains and the ecosystems would use it tests etc
AR: we might want language about what is expected of profiles how they interact and compatibility. But it’s still case by case which ones we want to have. I would want to discuss a profile that doesn’t have GC, that seems like an obvious thing. Back when we started talking about GC there was preference expressed in the CG that GC would be optional. But that’s also a separate discussion.
AB [chat]: Has anyone looked at what it would look like to target a specific profile from the toolchains?
DS: We are already living in the world where we’re supporting multiple variants of Wasm, some of the users want to support the latest versions, we want to target arbitrary features, most fo the applications in production only want to target the lowest common denominator, the world with profile wouldn’t be very different, that we’d have a flag and the world would be any different
CW: How will runtimes that don’t target GC target exnref, we could imagine typing a no GC profile to the structure of a tag, would be more fine grained than a feature tag
AR: one other small thing to DS: the deterministic profile is an easy case because it doesn’t actually affect toolchains; it only affects engines, in that it restricts what the engine can do, i.e. what execution paths the engine can take; it doesn’t restrict producers.
CW: We have to promise that no producer to rely on it, otherwise we can be messy
AR: yeah,m we dont’ want producers to do anything special for it. So it’s not that they have to, it’s that they shoudln’t.
PP: the procedural part of moving phases, normally we have tests and implementations. Just want to understand more. Is the only thing we change that certain things become optional?
AR: Not sure what you’re asking, but GC would be different from the deterministic profile, where it would take away some features
CW: I was interpreting it as a procedural question: how do we decide whether to add a new profile?
PP: Yes, if we define a profile that’s not in browsers, how do we standardize that?
CW: we don’t have a perfect answer for that yet
AR: In general, the way we decide this which is having a discussion, with GC, the way we make that a part of the GC proposal, but for features that have shipped where we want to introduce a profile later, that would be a feature discussion, a proposal even that goes through phases, we have to decide there has to be tools support, we have to apply our process to that as well with having tools that target that as well, with engines as well, that could be a requirement for having a switch for turning off, Our framework of profiles,
PP: Our acceptance criteria is 2 web implementations. Are we going to relax?
CW: it’s definitely arguable, we’ll certainly need new criteria for advancing things through the process.
AR: yeah, some parts will apply and some won't. We have this already e.g. for changes that only affect the JS API, only apply to JS engines. Also the annotations proposal doesn’t affect web engines. So we already have this problem, how to deal with proposals where the 2-web-engine proposal doesn’t make sense.
DG: one thing we should do is build this into the phase 2 vote for profiles, I think this is where we’ll have the mmosmt contention. We should discuss on the repo and document it. But we want to address where we have the most design contention ,and get consensus on that first.
BT: one of the stated non-goals is versioning. I don’t disagree but lots of people, implementers, etc do care about version number. So while it’s technically orthogonal there might be interactions. So we can’t completely ignore the problem of versioning.
CW: Hope we can keep it orthogonal, there have been several feature detection proposals, don’t think we have the bandwidth to pick that up
AR: if i understand Ben correctly it’s more about structuring e.g. teh test suite in a way that you can select versions and profiles, etc BT: also the toolchain perspective. If there’s an engine stuck at 2.0 forever, it may make sense to have the option in the toolchain
CW: Do we think we need additional spec mechanisms to make that happen?
BT: i don’t think it’s anything in the spec doc, it’s more about structuring the test suite. We have the approach that we don’t add behaviors to existing instructions. Considering that profiles is a subsetting mechanism, but we don’t want to add behavior to an existing feature that requires us to add a profile that restricts to previous behaviors.
CW: My hope is that’s not done with profiles, but we would have different opinions
PP[chat]: My second comment is on toolchain: they have to be ultimately aware of profiles, as in example already mentioned, targeting relaxed simd while assuming deterministic profile can easily break when running in non-deterministic environment. Maybe there needs to be a way to programmatically detect this.
AR: in terms of the artifacts we produce in the spec, it’s the test suite, and maybe we need a way to annotate tests with which profile or version they apply to. We have subdirectories now, but maybe if there are cross-cutting constraints, maybe we need to annotate individually. Haven’t thought it through yet.
RH: looking at the phases again: the only entry requirement that seems to apply here is mostly just consensus, that there’s a procedure that we understand and agree on. Doesn’t seem there will be spec interpreter, engine implementations, etc. so once we get consensus on the details, we can vote on whether to accept it? Doesn’t seem a lot of value in phase 2, 3, 4
CW: I wouldn’t be against a vote of supporting profiles in the web,
RH: yeah that’s good to separate out. I would guess that the profiles proposal could specify a future process? Proposals then could specify that they introduce a new profile
DG: also wanted to mention that as part of relaxed SIMD discussion, we did have one agreement that says that we are willing to adopt profiles methodology to the spec. Didn’t seem contentious, ,we can always codify it into a poll.
AR: another way to phrase, it would be acceptable to fast–path just the framework part
CW: We’re effectively having a consensus vote on a new procedure
RH: yeah that’s what I imagined. Having the infrastructure, we could just vote to accept it once we have the issues pinned down. Relaxed SIMD could advance with it. Doesn’t seem much value in individual phases.
CW: We shouldn’t tie it closely to relaxed SIMD, we can
AR: isn’t that a discussion we already had, that we agreed that we wanted a deterministic mode (where profiles was just the mechanism)?
DG: I would like to push on it, there hasn’t been a lot of discussion in the cg on it yet, I wouldn’t want to hold relaxed SIMD back. We did have some kind of consensus on having a deterministic mode. I would like to solidify that we agree that we will include a deterministic mode in the future, ,and if we formall agree on that I think it’s good enough to decouple relaxed SIMD from it.
CW: so we can agree that there will be a deterministic profile and relaxed SIMD can go forward and mention profiles
AR: the requirement for phase 4 is a complete spec, but the relaxed SIMD spec uses the profiles language. We are implicitly fast-tracking it already
CW: but it doesn’t commit us to a particular procedure. Teh editorial framework isn’t controversial, but the procedural part needs more discussion.
AR: it is kind of like fast–tracking the procedural part
CW: I wouldn’t want to hold back SIMD on getting agreement on the procedural part
AR: once we use it in the spec, it’s already written there
CW: but the failure case is, we end up with 2 profiles defined in the spec now (deterministic and full) but fail to agree on the procedure for more profiles and just end up with the 2. That wouldn’t be the worst thing.
BT: are the profiles going to be integrated in the spec document itself?
CW: with relaxed SIMD it will enumerate full and deterministic profiles, and future discussion will determine how to add more profiles.
AR: there’s an appendix where the profiles are listed in the spec
DG: I added a couple of polls, one that the spec will have a deterministic profile. That’s maybe a little premature, but we still do want to move forward with that soon. This also assumes what Andread mesntioned earlier, codifying the syntatic portion
RH: so this accepts the framework of having profiles in the spec, but not the procedure to add new profiles? So this makes deterministic and non–deterministic profiles and allows SIMD to go forward?
DG: I can also file issues, e.g. producural part, artifacts we need, and how to move infrastrcutre/syntactic things forward.
RH: I think it would be good to wait 2 weeks on relaxed SIMD and do it with the other stuff.
AR: agree with Ryan, we want to clarify what exactly we are voting on. I think we are more or less on the same page, it’s just about the procedural question and not conflating things.
DG: I agree but really want to make sure that relaxed SIMD gets wrapped up.
CW: is this about browser release windows?
DG: it’s more that the champions are moving on to other things and we want to make sure things are wrapped up and they don’t need to worry. It’s been depending on this nebulous thing for a year,
AR: I think we’ll be able to resolve it soon.
DG: thanks to Marat and Zhi for championing