- Where: zoom.us
- When: March 19, 4pm-5pm UTC (March 19, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: Ben Smith
- Email: [email protected]
None required if you've attended before. Email 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.
- Normative: Permit work in parallel during instantiation
- WebAssembly ESM integration for Phase 2 (spec, HTML PR)
- Growing shared WebAssembly.Memory and updating SharedArrayBuffer objects
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Ben Smith
- Ben Titzer
- Conrad Watt
- Dan Gohman
- Daniel Ehrenberg
- David Piepgrass
- Deepti Gandluri
- Derek Schuff
- Flaki
- Francis McCabe
- Jacob Gravelle
- Jensengrey
- Lars Hansen
- Limin Zhu
- Luke Imhoff
- Luke Wagner
- Pat Hickey
- Paul Dworzanski
- Paul Schoenfelder
- Sergey Rubanov
- Sven Sauleau
- TatWai Chong
- Thomas Lively
Daniel Ehrenberg
DE: queueing is a continuation of discussion from a year ago. JSC needs to do work during instantiation, different types of memory, may need to do more work. This PR yields to the event loop, to do work. Yields to the event loop unconditionally. All browsers need to do this. That was recommended to make things consistent.
BS: Were any concerns expressed on the issue?
DE: No concerns were expressed there. It was a normative change, maybe wait for implementations? Needed for ESM modules.
SS: I think there were concerns about [inaudible] yielding to the event loop.
AK: It was only Dan who mentioned that it was a performance concern.
BS: I assume that BT and LW are not speaking out so I would assume this is not a concern?
BT: So after you instantiate a module, you have to yield to the event loop once?
DE: between
BT: Oh, not sure about that, will try out.
LW: Makes sense to allow this kind of flexibility.
BS: So maybe we should try and see if there were implementation concerns?
LW: Probably won’t break anything in practice.
SS: Maybe make another proposal for that?
LW: May be a 2-hour patch, so I can try it out and see if it breaks anything.
DE: thanks
WebAssembly ESM integration for Phase 2 (spec, HTML PR)
DE: The ESM integration proposal is ready for phase 2. It has a dependency on top-level await, async work for compilation. There is ... we need the evaluate phase of the module to be asynchronous. I reviewed this with people who work on bundlers, the explainer has been updated.
DE: What do people think, should we put this in stage two?
BS: [describing phase 2]
DE: Lack of tests is because of no top-level await. Until then, it doesn’t make sense.
SS: Does it mean that the [inaudible]
DE: Not at the javascript level... this differs from how wasm modules are implemented in bundlers, since they are done earlier without allowing certain types of imports.
BS: Do you know of anyone planning to prototype this?
SS: We have a preliminary implementation in webpack, but is currently not up to date with the spec.
DE: We should consider native implementations necessary for moving ahead, but we have had positive feedback from tooling as well. We may be able to work on this at Igalia.
AK: Comment about dependency (top-level await)?
SS: I don’t think it’s really a dependency?
DE: It is, but we want to go forward with top-level await, at stage 2. I think it would be good if wasm moved forward with this too as a signal. It doesn’t make sense to ship in browsers until stage 3.
SS: My understanding, async modules are a hard dependency, but top-level await is just using it.
DE: I see that this is being developed in concert, so I think we should move them forward in standardization as well.
AK: I second Dan’s concerns that there is a strong enough signal. Changes are likely to come from the JS side, not our side.
BS: So ... is the premier concern?
[unanimous consent to move to phase 2]
AZ: In pthreads + memory growth, we use webworkers to implement pthreads. We allow JS work in those pthreads too. When you grow memory, it grows fine for wasm, but JS outside needs to update it’s views of memory. There’s no great way to do it, if you’re running JS and memory grows in another thread, it’s memory might be out of date. So we’ve been thinking about options here, some ideas for spec things.
BS: We were brainstorming how to solve this problem, whether we were missing some obvious solution. The major issue being, TypedArray views cannot grow out of under you, but ...
LW: When memory grows, they remain valid, they just reference a subset. For that particular range it should be accessible.
AZ: This simple cases can be handled, if you add a call to JS from malloc.
LW: You have to consistently refresh the buffer.
AZ: One option is to work around in JS, instrument the code, people need to find where to do this. Concerned about the lack of guarantee.
On the spec side, we could also call into read/write into wasm memory, if we provided a way to do that then we’d be safe.
We could also have a WebAssembly.Memory.seti32...
LI: ...?
BT: Your comment targets the implementation level, this is more the language level. The array buffer has length, and we can’t update them because of JS semantics.
LW: This would be a burden to insert refreshes. Is there any technical problem, other than that it’s annoying?
DS: The real problem is ensuring that the other threads are updated. You can pass an allocated pointer to another thread.
LW: That JS will receive the new memory, every time you read a new i32 you have to validate it.
BT: Every time you go through the memory object, you have to use buffer. You can’t cache it.
LW: For e.g. loops you would still need to access it once, that being said I can see the value of having a Memory.get/set... method
BT: Is it worthwhile to have grow memory sending post message?
LW: You wouldn’t have return to event loop to receive it, you have to handle the worst case pessimistically.
BT: You would still get a signal that you should update your views.
BS: My concern is you’d still need to create a view to pass it to a WebAssembly API...
LW: You could imagine that you have a getView that creates a new one that is always valid. You could polyfill... the object itself could be implemented in JS.
BT: could we put something on the prototype for out of bounds accesses?
AK: Not sure you can handle OOB here because typed arrays are too fancy.
AZ: We could polyfill this in the meantime. May want to tell users that pthreads + memory growth are not an option.
LW: Abstraction boundaries? Is there any interface between the user an wasm memory. We have our own JS that we can audit by hand. Users can write their own JS. Very risky.
BS: You would suggest them use this slower interface only for the pThreads+memory growth case?
AZ: yes, possibly
BT: How prevalent is it that people write code accessing the buffer?
AZ: Extremely common, how often the buffer is changing is hard to tell. To some extent it depends on how common this is for users to use. It would be nice to think about spec part.
BS: Seems like the type of thing we are unlikely to do here, but some JavaScript experts here might want to do it and throw it over the fence?
AZ: It’s on WASM.Memory so maybe it should be this group...
LW: ...
DE: The idea is to have wasm memory allow direct reads, even when growing.
AZ: Yes, have memory.readI32, writeI32, same as wasm memory.
BS: Someone should write something up, or write a polyfill probably to move this forward...
AK: Write-up is probably a good next step.
[some discussion of in-person meeting logistics]