- Where: zoom.us
- When: June 22nd, 4pm-5pm UTC (June 22nd, 9am-10am Pacific 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.
- Discussion: WebAssembly, Unicode and the Web Platform (pre-recorded, see linked issue; slides) [20 mins]
- Deprecation of cross origin module sharing [20 mins]
- Wasm/JS API integration for resizable buffers (Shu-yu Guo) [20 mins]
- Closure
None
None
Jacob Mischka
Deepti Gandluri
Dan Weber
Rick Battagline
Sean Westfall
Chris Fallin
Lars Hansen
Nick Fitzgerald
Paolo Severini
Garrett Gu
Saul Cabrera
Ioanna Dimitriou
Conrad Watt
Dan Gohman
Sam Clegg
Jay Phelps
Ezzat Chamudi
Alex Chrichton
Francis McCabe
Paul
Luke Wagner
Daniel Wirtz
Slava Kuzmich
Andrew Brown
Jacob Abraham
Piotr Sikora
Andreas Rossberg
Camille Lamy
Lutz
Thomas Lively
Kaith Miller
Emanuel Ziegler
Asumu Takikawa
Mingqui Sun
Ryan Hunt
Jakob Kummerow
Rich W
Sergey Rubanov
Aaron Turner
Daniel Hillerstrom
Flaki
Alon Zakai
Sam Lindley
Jlbirch
Heejin Ahn
Peter Heune
Ross Tate
Dan Gohman
Connor Hicks
Zalim Bashorov
David Piepgrass
Acting chair to volunteer
Discussion: WebAssembly, Unicode and the Web Platform (pre-recorded, see linked issue; slides) [20 mins]
DW: Curious about the thoughts of other language implementers - would like to hear about other opinions?
FM: IT seems that you are recommending we have unicode, except not actually unicode and instead we have whatever we want?
DW: The unicode standard says that in normal processing you have isolated surrogates?
FM: It says it’s undefined what happened when you have that.
DW: Maybe when you transfer it, if you split a string and separately compile it, and pass the isolated surrogate around.. We are preventing the first part being correct. When we call a filesystem API or networking API - we want this to be well formed
FM: First of all, our focus is not on languages but on the overall ecosystem - languages are a means to an end - the real focus is on supporting a potential ecosystem - supporting modules and publishers, essentially being a marketplace of interchange. One thing that IT is not focusing on internal structuring of a library or an application - if you are structuring things internally, there is a much greater sharing of knowledge that you would expect in the ecosystem - this is reflected in the choice of type language, it is very limited, there are things you can’t express, there is no intention of supporting this. Hashmap is not something we will be supporting, for example- if you were to use IT to partition and put it back again you would be in a lossy situation just because of the restrictive types - this is pointing to a misunderstanding of where IT fits into the scenario. The archetypal situation is at the boundary when you are going from using your code to someone else’s at the boundary. You could be using it for other purposes, but that is the picture we are aiming at and it is going to reflect our choices. Picking strings - picking a format that is compatible across all boundaries. We are not assuming a networking interface, just a boundary - having a well formed notion of a string is useful because everyone knows what to expect in that case. Ill-formed string is only one of the potential ill formed types, I would argue that if you were supposed to communicate that odd type with someone else, you may have some trouble with it - IT has some other components - resource types for examples - if you were trying to communicate an odd type to yourself.. You will have trouble with it
KM: I’m curious- you mentioned that this is an ecosystem consideration. I would expect the DOM to be a large part of that. AFAIK DOM engines primarily support UTF-16, so perhaps it would be worthwhile to have a low-cost bridge. Is that part of the disagreement?
LW: For those sorts of the DOM API, the place to solve that is in the JS API as these are uniquely specific problems. You just don’t know in the component model
KM: The task might be very large because the surface area of the DOM is very large. Millions of lines to change.
LW: I didn’t mean that Web APIs should change- The JS API would be a good place if you wanted to turn UTF16 into the DOM string
DW: AS is being used in non-web cases as well - we could annotate WASI APIs as well, we could annotate.. But it is not very convenient, we want to have a solution that works in either case, without having to worry about overhead etc. If you look at the inverse, where you use AS one side and JS on the other side you end up with a double reencoding. We can solve this in the Web API, but the problem runs deeper than that, we should be able to solve it better
CW: There are two issues here: first if you have a WTF-16 string, passing through the boundary is lossy. Second, you have a double re-encoding. The latter could be solved in a lossy way via UTF-16 support.
DW: That’s already significantly better, it still won’t be correct - if that is all we can get
DW: Possible future steps: continue discussion at future meeting, create IT subgroup, straw polls.
DG: Let’s continue the discussion in a smaller group and come back for straw polls in one month.
<CL Presenting - TODO - add slides>
FM: What is an agent cluster - it’s an HTML concept - in JS it is the thing that could have synchronous access to each other - if you are completely cross origin, cross site, this is what determines the execution context, if you have different agent clusters, you have different contextts
CW: IT basically defines the group of shareable objects that we can transfer between
CM: Can’t you post message them?
LH: Yes, but the shared object themselves are limited to the agent cluster.
JP: Is this about synchronous sharing, or transferable objects via postmessage
CM, KM, DG: Yes, this is just about postmessage.
DG: The other good thing to note is that among browser vendors, there appears to be consensus that this would be a good thing to do. CM, is that correct?
CM: We have broad consensus, we haven’t done an explicit call for position, but the general responses to deprecating document.domain have been positive
JP: In the future to share cross origin, you would need to download twice, compile twice, and instantiate twice
KM: correct, but there is very low usage
KM: IS that % of pages loaded, or the unique pages?
CM: Pages loaded
DG: We would be disallowing postmessaging modules across modules within the same agent cluster. Does anyone object?
JP: Could see myself doing this, but acceptable compromise for the goals mentioned
FM: What’s the action item that we would be taking?
KM: It would be a change in the HTML spec.
DG: There may be some editorial things to change in the JS API as well, but I don’t think this would be a meaningful change to the JS API.
CM: The first change could be in the wasm spec where we check for Origins instead of agent clusters.
DG: Sounds like there are no objections - concrete action items: Change Wasm spec to mention origins instead of agent clusters HTML change Engine implementations will need to change disallowing post-message of wasm modules across cross-origin bounbdaries
Wasm/JS API integration for resizable buffers (Shu-yu Guo)
SG: Recap: Had presented PR #1300 on integrating resizable buffers. Feedback was to come back after stage 3 in TC39. There are some API surface changes on the JS side. Previously the resizable buffers would be separate constructors. Now we reuse ArrayBuffer and SharedArrayBuffer and pass an options bag to make them resizable. None of the semantics have changed.
SG: Currently you can get a buffer from the WebAssembly.Memory object. This proposal adds a new resizable getter to those buffers. If you want to make it resizeable, you call toResizableBuffer, which vends a new buffer and detaches previous buffers.
SG: The only change from last time is that instead of vending two array buffers, there will be one ArrayBuffer
CW: If you call toresizable twice, it doesn’t detach correct?
SG: Yes, if you call it twice with no intervening toFixed calls, then it shouldn’t unnecessarily detach the previous one.
AZ: When you grow, it no longer detaches if it is a resizeable buffer, and on the JS side the views continue to be usable?
SG: That is correct, got a review from littledan - some open questions should we hardcode the length? More reviews welcome SC: Is there support for shrinking? The JS one can, but the Wasm one can’t?
SG: Yes. These buffers are designed to be implemented as in-place grows. When you resize it will commit the physical pages at the end of the reserved space. Shrinking is not guaranteed to give the pages back, but semantically it is allowed and will track the length for JS-vended buffers. Shrinking is not allowed in WebAssembly-vended buffers.
DW: HAs it been considered that if the underlying memory is resizeable on the wasm side (e.g. when the initial size is not the max size), you would get a resizeable buffer on the JS side - has this been considered?
SG: In the previous iteration of the PR because we were proposing a new kind of AB, the back compat concern was stronger because we can’t change the default behavior - given that it’s a different mode of the same type - maybe there is less concern there? The concern is back compat, we always want to vend resizeable buffers when it is coming from the JS side, but there may be code already in place, so it’s not worth making the backward breaking change
DW: Would be nice if it were possible, but I understand the back compat concern.
SG: It depends on who wants to do the legwork
LW: It would be highly probably that something would break, so we would have to walk this back anyway
JP: Anyway we could signal during instantiation that this is what we want?
SG: That has been brought up as well, it makes sense to make sense the Wasm JSside constructor - it’s less clear how easy this would be to do just in the Wasm side. This is very specific to JS so we could explore the custom section portion of it, but not much enthusiasm there
CW: If they stick to the discipline, it always look resizeable on the side
SG: It would probably be taken care of by a flag in emscripten for example
DW: This would not work during instantiation because the start method would need its imports to use the resizable buffer.
CW: This is an ergonomic change for a self contained JS app that always wants to make sure that an AB is always resizeable
JP: It’s a bit of an odd API because of the mode switching. It’s non-obvious that calling toResizableBuffer would also affect the memory.buffer.
SG: CW help design this in the beginning, and I like where this is now - CW’s proposed hypothetical might work, it’s just more codegen, and I expect that this is more generated code, but not written by hand
JP: Agree. That’s why I’m not too concerned.
TL: Can you explain the back compat hazard again?
SG: I’m imagining that there might be code that depends on getting the bugger, caching the bytelength, and assuming that it never changes
JP: Wasm memory will likely eventually shrink, so there’s a reverse risk as well
CW: Something may also depend on the buffer being detached after grow
DG: Any concerns from browser vendors or anyone else?
JP: Has it been considered that we might have Memory.resizableBuffer or some other way to get directly at the resizable buffer?
SG: That was one of the earlier designs, my initial design - CW among others convinced me that this is more ergonomic - it’s too weird to have two different JS ABs aliasing the same backing store, it sounds like a user and implementer footgun.
SG: To be clear, want to explicitly move to the implementation phase so the work can be done in parallel with the JS work.
DG: This would be at phase 3.
SG: You all normally have another discussion to ship?
DG: Yes, or to say that it’s an official part of the spec at phase 4.