- Where: zoom.us
- When: May 12th, 4pm-5pm UTC (May 12th, 9am-10am Pacific Daylight 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)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- Poll: Propose WebAssembly BigInt<->i64 conversion in JS API for phase 4 (spec PR).
- Discuss global ref.func initializers complicating validation (reference-types issue#76)
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Alshamma
- Andreas Rossberg
- Arun Purushan
- Arun Purushan
- Ben Smith
- Conrad Watt
- Deepti Gandluri
- Derek Schuff
- Emanuel Ziegler
- Francis McCabe
- Gergely Buday
- Heejin Ahn
- Ingvar Stepanyan
- Jakob Kummerow
- JP Sugarbroad
- Keith Miller
- Lars Hansen
- Luke Wagner
- Manos Koukoutos
- Mingqui Sun
- ms2ger
- Nick Fitzgerald
- Paolo Severini
- Pat Hickey
- Paul Dworzanski
- Petr Penzin
- Rick
- Ross Tate
- Ryan Hunt
- Sabine
- Sven Sauleau
- Thomas Lively
- Tobias Tebbi
- Wouter van Oortmersson
- Zalim
- Zhi An Ng
Thomas Seconds
Poll: Propose WebAssembly BigInt<->i64 conversion in JS API for phase 4 (spec PR).
https://docs.google.com/presentation/d/17hzIr9uGWv4krJC9W9fWhWzx-6jA4rzLkTLKT8leeo8
SS: Only thing missing for phase 4 is consensus from CG
SS: Only thing to mention is no implementation in reference interpreter as this is a JS API feature
POLL: WebAssembly BigInt<->i64 conversion in JS API for phase 4
| SF | F | N | A | SA |
|---|---|---|---|---|
| 17 | 10 | 2 | 0 | 0 |
Discuss global ref.func initializers complicating validation (reference-types issue#76)
https://docs.google.com/presentation/d/1EOwIRSpW3kJlSdiR529rIaXXfvzIP221LK5qv8oeGbE/edit?usp=sharing
From the slides:
- Defer validation of global initializers until element section is read
- Split off global initializers into their own section after element section
- Refine allowed targets to include anything specified before code section
AR: 4th option would be to use element section - plug in another kind of section that plugs in ref declarations, not sure that’s worth doing either
BS: drawback is that we already allow those in the elements section
AR: There has to be a special case for the element section anyway - we could limit that section to the compressed section.. This is all kind of making it arbitrary, but any solution here seems to be arbitrary
BS: global init in their own section - global initializers can get more complicated, depend on more info in other sections, might be valuable to do this, think of module as set of declarations, then definitions below
AR: That was my thinking too, right now global initializers are trivial - ref.func are the only ones that allow you to reference other things. This would be a more forward looking solution in a way, it’s also obviously a bigger change.
LW: one argument towards (3), it’s not ref.func that is the problem, we need to know which func global tables can be aliased before compiling code. Everything before code section doesn’t really matter for compiling. E.g. if you have a func in the exports, but another module can stick that in the elements section. The weird detail is that you have ref.blahs that show up in the code section - we have all the data before this section .. that justifies how we’re setting up the code section. Three is the least work possible, and it achieves the goal of what we actually want to do here.
AR: agree that 3 is the least work, it makes a number of assumptions about what is relevant for streaming and what is not, what is code and what is not. An argument for (2) is that we don’t know global initializers get more complicated. It’s not clear that’s going to happen, but it would be nice if we did not have to bake in narrow assumptions about what you want to stream (or not). The distinction between declarations and definitions is useful. Globals are the only thing that are mixing these.
LW: If we got to a point where we have loops oin that section, where we want to JIT them, we can figure out what we get to it, I don’t see it be very likely.
RT: Is one option to have func section to have a bit that says if it’s allowed to escape or not.
JS: That’s what the element section is doing, the element section doesn’t happen till the function section… the argument about compilation is strange to me, You could be half way through a compilation, see a large expression.. And it’s back to the same thing
BS: the primary issue is about ordering of the section, so you can do validation in order
RT: If you put the bit in the functions section..
AS: basically the option 4 mentioned, it would have to be a separate thing we have to put somewhere else
LW: To be regular we need it for all kinds of functions that could be refed in the future.
BS: if we had to choose between 2 and 3, 3 seems easier, we consider this to be the env, my concern mostly is, if we extend what global init can do, to include ref func, if we ever get to a point where we have complicated enough initializers, then we add the global init section, and that section can only be constant or ref func.
LW: It really is hard to imagine putting loops in global constant expressions
BS: imagine we add a section that occurs after the globals section, maybe structure definitions, then you need this to validate the global initializers.
LW: If it’s type stuff it should go before the globals section...
AR: more abstractly, the assumption that code gen is the only thing that needs this information may be too implementation driven, though i can’t come up with a scenario that is different
LW: Validation is happy with what we have, we’re talking about an implementation perspective here, we need to know if it escapes to some strange thing
AR: this is now part of the declaration that might come after certain uses, and making the assumption that these uses don’t care. For existing engine and language, reasonable assumption. Is this true in a more general sense? What’s the rationale behind this on a more abstract level. This is just ad hoc, might be the wrong thing in the future.
LW: Worst cse is if you don’t have this implementation detail, you delay the compilation, so it seems like it would only be a problem if we made it be that way...
AR: not just code generation, i can imagine some ways where you want to figure out the layout of stuff in a streaming fashion, and how certain data structures related to each other, you might want to know if stuff can escape, and this can influence choices you make downstream - this might not be limited to code gen by itself
LW: The exports section which is at the end of all the section, also makes a thing aliased, so it seems like you have to see the module environment before you can make any nuanced data structure decisions, and that’s already the case, it’s less than 1% of the bytes, so it’s not like we’re leaving performance on the table
AR: is it still when you have nested modules?
LW: all the module codes go after the code section
JS: we have this streaming validation, and with this, we can’t have streaming validation, need something to refer to information that comes after. Until we actually start to see prologue sections that become large enough to do two-pass / delay, it’s a difficult argument to say we have a problem.
LW: With 3 validation is streaming, it’s only option 1 that makes us wait
JS: disagree, even if you allow it… if we scan a ref.func within global section, we say it’s okay?
LW: Yes, exactly - and any other place that ref.func might show up before the code section
RT: essentially, section 1 through 9, should be viewed as all done together...
LW: They all serve to declare ref.func, anything before the code section will be on the declaring side. All ref.funcs before the code section serve to declare the ref.func.
BS: okay with this, (3) makes it simpler to move this forward, in the future we may want (2), we can still defer it to the point when it is necessary. So it’s only somewhat ad-hoc.
AR: IT will be more ad hoc at that point, in the interest of moving forward, I agree this is okay
TL: have to be arbitrary order as well
FM: The property you want to keep is declaration before use - it seems to me there are tow constraints that will collide - fixed order and declaration before use. If you allow multiple occurrences of the section, you keep the properties that you want to keep
JS: we lose a lot of canonicity in encoding, what happens if two sections say different things
AR: They would just be concatenated. The semantics of multiple sections would not be difficult, but it makes decoding unfortunate, because you can’t allocate data structures ahead of time
LW: validation will be tricky, you have to think about binary section order to see if it’s a valid index.
BS: sounds prone to a lot of bugs, discrepancies between engines.
JS: Sounds like 3 was getting some pretty good consensus there
BS: agree (3) sounds like we’re aligning on it. Worth taking a poll? How do we want to move forward. Can’t really poll cos we did not suggest it as a poll on the agenda. Other opinions in the group?
RH: If anyone disagrees, maybe that’s good enough to move forward, that’s good enough to move forward.
BS: Silence of agreement.
RH: Github issue is on the slide, if anyone still has issues follow up there.
BS: no other items. One last comment i'd like to make. I have a form for the Garbage Collection Subgroup. If you are interested, please go to the issue.