- Host: Google Hangouts
- Dates: Tuesday November 28th, 2017
- Times: 9:00am–10:00am Pacific Time
- Location: same Google Hangouts link as before
- Contact:
- Name: JF Bastien
- Email: [email protected]
None required if you've attended before. Email JF Bastien to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be a Google Hangouts call.
- 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.
- Meeting times + collaborators in Asia-Pacific
- Discussion of meeting time logistics
- POLL: We should hold every third video call at an APAC friendly time.
- POLL: We should time the meeting to avoid conflict with TC39.
- The name of WebAssembly.Global
- See WebAssembly/threads/issues/49, discussion stalled
- Poll-worthy?
- The type of immutable globals exported from instances
- See WebAssembly/threads/issues/73, discussion stalled
- Basically, either change existing API incompatibly or live with complex API
- Poll-worthy?
- The type of the wake count argument and return value for atomic.wake
-
Spec text changed this to i64 but poll at CG mildly in favor of older i32:
SA A N F SF 2 2 11 4 0 -
Would be good to nail this down now, code is landing in implementations
-
Discussions bogged down on what TC39 may or may not want to do
-
POLL: Revert to i32 with trapping in (the implausible) case of overflow
-
- Conditional Segment Initalization instructions
init_memory/init_table- See WebAssembly/threads/pull/79
- POLL: Should we limit these instructions to only being valid during instantiation?
- Closure
- Require custom sections after all known sections
- See WebAssembly/design/issues/1153
- POLL: Should we specify that custom sections must come after all known sections?
None
- Ben Smith
- Brad Nelson
- Heejin Ahn
- Ben Titzer
- Jacob Gravelle
- Sergey Rubanov
- Tyler McMullen
- Yury Delendik
- Luke Wagner
- Eric Holk
- Thomas Nattestad
- Limin Zhu
- Pat Hickey
- Michael Ferris
- Michael Holman
- Marakat Durkan
- Deepti Gandluri
JF away, BradN deputized to run meeting.
Seconded by Thomas Nattestad
Glanced at open issues. Nagged folks.
* Discussion of meeting time logistics
POLL: We should try a APAC + EMEA friendly time for the first meeting in January. Unanimous consent.
POLL: We should time the meeting to avoid conflict with TC39. Tabled so we can talk with TC39 attendees.
* See [WebAssembly/threads/issues/49](https://github.com/WebAssembly/threads/issues/49),
discussion stalled
Discussion
LW: Global kind of make sense, it's similar to JavaScript's notion of a global.
BT: It's kind of a lie, it's not global in the sense of global to all threads.
LW: The text format would change. It would be a breaking change. All our things are with respect to a module. Seems the right name from a core webassembly perspective.
BS: We don't have a better contender, there's not really a better name.
BN: Thread local?
LW: When we do pure wasm thread, it would be instance specific.
BT: You really want to make it a property and not make it something separate.
LW: I think thread locals in a pure wasm world would get a new definition.
BN: Sad it would be a breaking change.
LW: I think rossberg was in favor of keeping it.
BS: I don't think we're gonna make anymore progress.
POLL: We should stick with WebAssembly.Global.
| SA | A | N | F | SF |
|---|---|---|---|---|
| 0 | 0 | 3 | 7 | 5 |
EH: N because have no opinion.
1. The type of immutable globals exported from instances
* See [WebAssembly/threads/issues/73](https://github.com/WebAssembly/threads/issues/73),
discussion stalled
POLL: We should specify that immutable globals return WebAssembly.Global?
Discussion
BT: Is there an advantage besides uniformity?
BS: Not sure there is. We could instead have it vary based on if mutable.
LW: Imagine importing a mutable as immutable in another module.
BT: You wouldn't expect the value to change or to export as a subtype.
BS: That's an argument for keeping a separation. It makes it obvious that the numbers are not mutable.
LW: Here's an argument maybe. A Global could have a nice accessor, that would tell you what type it is. A raw number would lose something.
BT: There might be global we would allow to be exported that don't have a JavaScript type.
LW: Like passing i64 type functions between modules.
BN: I like that argument.
BS: We'd have to have some kind of error if you mutate / types don't match.
SR: If they TC39 proposal for global passes, it will be global.WebAssembly.Global which seems weird.
BS: Maybe rather than a poll. We could have an action item to have a browser try it and see what breaks.
AI(lukewagner): Try it and see if it breaks.
* Basically, either change existing API incompatibly or live with complex API
* Poll-worthy?
* Spec text changed this to i64 but poll at CG mildly in favor of older i32:
SA | A | N | F | SF
|----|---|---|---|----|
2 | 2 | 11 | 4 | 0
* Would be good to nail this down now, code is landing in implementations
* Discussions bogged down on what TC39 may or may not want to do
* POLL: Revert to i32 with trapping in (the implausible) case of overflow
BS: It seemed like most people just didn't care, so I took the liberty to go with i64.
BN: Is there a poll we could suggest that could clarify this?
LW: Lars just wants it settled.
BS: Type doesn't make a big difference to me. This is largely theoretical.
AI(Ben Smith): Change back to i32 (as per poll result).
* See [WebAssembly/threads/pull/79](https://github.com/WebAssembly/threads/pull/79)
* POLL: Should we limit these instructions to only being valid during instantiation?
BS: There was a recent proposal for conditional segment initialization. The new proposal adds instructions to do initialization. You provide the index of the segment as an immediate. We thought maybe this should only be available during instantiation. JF wanted to know why not all the time?
LW: The argument for restricting it, is there's no way to know when you can throw away the data segment.
LW: Seems like a pretty silent cliff.
BS: Because JF isn't here to advocate for himself, I'll read his comments. ""
BT: I don't think it makes sense to require a global analysis to know if you can throw away the data segment. Could we add another bit to indicate if the block should live outside the start function.
BN: I kinda like that. Maybe more complex.
LW: Could we start without and see if anyone wants it?
BS: We currently don't have this functionality. We're adding this functionality for threads, do we have a use case for this?
BT: Games might want to bundle assets this way.
BN: But most games usually want assets in separate resources.
BT: This could be useful if they have a chunk of data they want to mutate.
LW: Unlike native, this isn't just mmaping, you have to do a copy. Seems like then you might want to use a file.
BT: It gets you most of this functionality, with a small change.
BS: Do we want to add the additional complexity to allow it? Or push to the VMs.
BN: It seems unfortunate to require a global analysis to calculate this.
TM: Being able to lazily init memory might be a big savings for us.
BS: You're saying rather than copy data in, you could decide at a later point to do that copy?
TM: Specific path through the webassembly code could do that.
BT: The way you'd do this without this mechanism is either use something in the platform, or do it yourself and end up with the memory duplication.
LW: We might be able to get a useful copy of write type mapping.
MH: What is your use case? We have a limited set of fast memory.
TM: We plan to always create a fast memory. We're running Wasm on the server. We're using cretonne, but not any of the spidermonkey machinery for it.
BS: To try and move forward, it sounds like we're interested in having this functionality. It sounds like we're mostly not wanting to do global analysis. So it sounds like we're going to want this bit proposed by Andreas.
LW: It's observable if you call the op but didn't have the the flag set.
LW: The other idea was that if you were transitively called from the init function.
BS: I think we can follow up on github for this.
* See [WebAssembly/design/issues/1153](https://github.com/WebAssembly/design/issues/1153)
* We currently allow custom sections anywhere, but since most (all?) producers currently put
them at the end, we may have incompatibilities in implementations.
* POLL: Should we specify that custom sections must come after all known sections?
Tabled
Adjourned