- Where: zoom.us
- When: October 29th, 4pm-5pm UTC (October 29th, 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
- Feature detection proposal discussion
- MVP compatibility (WebAssembly/feature-detection#5)
- Poll to rename from "feature detection" to "conditional compilation"
- Trapping semantics of bulk memory operations (WebAssembly/bulk-memory-operations#111)
- Recap of previous discussion
- Poll to change trapping to occur before writing if any bytes accessed would be OOBs
- Updates about next in-person meeting
- Tentative dates mid-week of Feb 10th, hosted by Google in the Bay Area.
-
Closure
None
None
Andreas Rossberg
Francis McCabe
Conrad Watt
Arun Purusan
Alex Crichton
Lars Hansen
Deepti Gandluri
Adam Klein
Heejin Ahn
Thomas Lively
Michael Starzinger
Zhi An Ng
Ryan Hunt
Flaki
Ben Titzer
Alon Zakai
Jacob Gravelle
Ingvar
Luke Imhoff
Ms2Ger
Nick Fitzgerald
Peter Jensen
Petr Penzin
Rich Winterton
Shravan Narayan
TatWai Chong
Derek Schuff
Lars seconds
TL: The new mechanism enabled by this proposal is conditional compilation, not restricted to feature detection, and the condition could be features.
BT: Do you have other options? A more general option that doesn’t imply code generation?
TL: Agree compilation maybe not the best term, open to options
AR: Conditional sections?
TL: As written today, that’s a great name for the proposal, good transition to my next changes
TL: Short offline discussion to bikeshed the name, but are there issues with renaming?
TL: Goal is to promote cross engine compatibility, it’s currently not compatible with MVP engines, the way the design currently works is that it introduces conditional sections .. . In order to have MVP compatibility this needs to work with conditional segments, the process of parsing a binary becomes not parse some sections and concatenate, with MVP compatibility this becomes more complex, the other downside is that it introduces semantically significant changes. We don’t have custom sections that change the semantics that change the … How important is supporting MVP engines? In the long term/medium term, is it important to support MVP modules, without having to worry about MVP compatibility?
TL: Interested in hearing feedback
TL: Personally feel, most engines eventually will support new features
BT: If it’s just a matter of adding new sections, then that may not be bad, the choice is not binary, if we fundamentally change how sections work then it’s further away on the spectrum
TL: Doesn’t fundamentally change about what it means to be a Wasm module
LW: There is a gradual following of standardization of features, it’s good to go the simpler route
TL: Is Keith on the call? Discussion on the proposal
TL: Anybody else have comments, and concerns?
CW: MVP engines may already be left behind, that’s already an implicit assumption
TL: On the tools side we haven’t decided when to make the switch, I also have the sense that’s the implicit assumption
TL: Nobody strongly disagreed, will continue along the current path with more discussion on the issue tracker
<Ryan Hunt presenting slides>
RH: Are there any general concerns?
CW: so the problem with just system memmove, the current spec tries to pre-empt this problem but fails to accomplish the goal, so I’d be strongly in favor of going back to the bound-checked version as suggested
TL: Sounds good
CW: To be clear, this will still have a slight difference from the MVP, with this reversion the segments will be bounds checked one by one, and not when everything is completed
LW: that part of the change sounds reasonable
RH: Agree with that
TL: is the behavior of a 0-byte access one-past-the-end remain valid?
RH: 0-byte access is always valid, this doesn’t necessarily change that, and there are no pkans to change that
DG: any other concerns? Doesn’t sound like it. Ryah, do you have what you want form the community?
RH: should we do a poll?
DG: yes, do you have specific wording in mind that you want to propose?
RH: what’s on the slide:
revert the behavior of memory.copy/fill to trap if any access would be out of bounds, before doing the writes.
LH: this also includes the change to memory.init, right? It changes in the same way to mirror memory.copy?
RH: Yes..
LH: Memory.init was changed the same way as memory.copy
RH: yes, that’s the intention
DG: so this poll includes memory.copy, memory.init
AR points out that this applies to table operations too.
RH so yes all of the operations
TL: there are init, fill and move, for each of table and memory.
DG: so this poll applies to all of the operations, to trap if any access would be out of bounds, before doing the write.
| SF | F | N | A | SA |
|---|---|---|---|---|
| 12 | 11 | 0 | 0 | 0 |
DG: Ryan, anything else?
RH: no, thanks.
Next in-person meeting will be hosted by Google in the Bay Area. we’re looking at the week of Feb 10, don’t have exact dates yet since we are in early stages of planning.
Other topics?