- Where: zoom.us
- When: June 12, 4pm-5pm UTC (June 12, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: JF Bastien
- Email: [email protected]
- Name: Ben Smith
- Email: [email protected]
None required if you've attended before. Email JF Bastien or Ben Smith 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.
- Update on Conrad Watt's work on threads proposal
- Update on Layer 1 Compression (Katelyn Gadd)
- Discuss module serialization via indexeddb in v1 spec (Derek Schuff/Luke Wagner)
- Closure
None
- Ben Smith
- Ben Titzer
- Conrad Watt
- Deepti Gandluri
- Derek Schuff
- Heejin Ahn
- Jay Phelps
- John Hall
- Limin Zhu
- Mark Miller
- Michael Holman
- Pat Hickey
- Richard Winterton
- Sean Westfall
- Sergey Rubanov
- Sven Sauleau
Derek Seconds
Implementation Limits? (Ben T)
4k compile limits. Some small differences with each of the engines. Compile vs validate, was different on FF. Limitation for initial size of memory -- JSC and FF enforce smaller limit as validation error.
TAG guidance on indexeddb and modules (Dan E)
Conrad watt presenting: https://drive.google.com/open?id=1JZF_PP6OmkpTMSDAvJjDp_HDL9kDuV_Y
Bounds checks: basing decisions on GH issues. Seq Cst ordering, everything appears atomically. Not particularly onerous. Some knock-on effects. JS already does this. JS length of ArrayBuffer is fixed. In JS bounds check can be operational, w/ wasm memory is changing, affects consistency. So values that trap/not trap based on length can affect model.
Pretend grow memory does atomic write, and other operations do atomic read of memory length. Non-atomic accesses have to do seq cst synchronizations, but only for length.
[Some zoom presenting slides troubles]
MM: So you can only change memory by growing, right?
CW: There is a future proposal to add memprotect, which is kind of like shrinking memory.
MM: The memory protect thing… about that?
CW: On the agenda is a link to a PR that describes how to fix instantiation in the presence of memprotect. The only question is whether people are happy about what it should do.
MM: Are there design choices there that are not clear?
CW: Adding memory protect invalidates some assumptions that are made, guarantees that you can make. Not sure if this should block memory.protect.
MM: Given mem protect, are the design choices forced on the memory model? Or are there open questions that we should discuss in the future.
CW: I think the model will make sense, JF reminded me to take memory.protect into account.
MM: The choices are forced.
CW: Forced sounds negative, meant to be intuitive :-)
Other memory model issues: WASM wait/wake needs to agree with JS wait/wake, but JS spec had a mistake/bug. Got consensus on a fix at March TC39.
Current spec for host environment doesn’t work with threads, a host function runs all in one step but other threads need to be able to observe intermediate stages. Specify host as an abstract machine?
Postponed because KG isn’t here [BS: this was my fault, I accidentally wrote the wrong date on the CG meeting announcement]
Derek: originally we decided to allow caching module storage in indexeddb explicitly.
The other option is to allow implicit caching when you using instantiateStreaming.
AFAIK, Mozilla is the only implementor [Actually, Edge implements it too]. We haven’t sent it to the WG because of implementation status.
We’ve been discussing module caching in v8. We and others have started implementing baseline compilers, which makes this less valuable.
Luke has suggested unshipping this feature, because it may be less useful, less valuable, and not implemented. Some other issues w/ double keying.
On the Chrome side we’ve started implementing implicit caching which we’re going to be doing regardless.
Propose that we remove -- actually not in the WG spec, so actually just removing from the plan.
JP: Is that unrelated to postMessage of module to worker?
DS: Yes…
JP: I thought structured cloning and storing in indexeddb is the same thing as far as the spec is concerned.
DS: It’s kind of different… the module in a way represents the compiled module and the module bytes. Part of the problem is that w/ baseline compilers and tiering, if you compile the module the VM does something, but you don’t know what it has done yet. On Chakra may have done nothing yet. You really want to store the actual compiled code. Some VMs will specialize the module to the instance, so may be worse if cloned.
We’ll still want postMessage -- we need more spec work so we can allow postMessage to worker. Have the same problem potentially w/ workers though.
JP: Hoping to figure out (using iframes), if wasm ever becomes prolific, problem w/ big standard libraries on each website (like jquery). In this case it might be worse since the libraries are large. CDN usage would be a pretty important thing. There doesn’t seem to be a way for a CDN to cache its module. How can we solve this?
DS: IDB is nice in that it is explicit and reliable, we need some way to provide that to developers. One way we could do that is with the cache API.
JP: Is that service workers?
DS: It is spec’d by service worker spec, but it can be used outside the service worker. That was one of the original objections to adding serialization to IDB. 2 years ago, we thought it would be simpler to implement this in IDB, but perhaps we were wrong. The cache API will likely make this easier. The capabilities that IDB caching allows will be valuable, we just need a new mechanism.
DS: Any thoughts from apple/MS people?
MH: Curious about speccing this, since it was just structured clone. Happy to see it gone though :-)
BT: TAG review about the postMessage API. There was a spec repo pull request from Dan that we need to look into.
[chair accidentally started meeting incorrectly, so it started a “free” meeting. The VC meeting ended abruptly as a result]