- Where: zoom.us
- When: June 26, 4pm-5pm UTC (June 26, 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.
- Discuss removing ahead of time bounds checks during instantiation
- TPAC Early Bird registration is open; discuss which days of TPAC we should use for wasm CG/WG
- Update on Layer 1 Compression (Katelyn Gadd)
- POLL: Disallow IndexedDB serialization of WebAssembly.Module
- Discussion: Why not have native wasm threads?
- This was originally discussed in the May 2017 meeting, but there are some recent concerns that this may be difficult for non-web embeddings.
- Discussion: raise import/export limit to 1 million?
- POLL: Allow creation of default i64 global values
- POLL: Include in v1 spec: [spec] Normative: Support [Serializable] for WebAssembly.Module
- Closure
None
None
- Alon Zakai
- Andreas Rossberg
- Anirudha Gupta
- Ben Smith
- Ben Titzer
- Conrad Watt
- Daniel Ehrenberg
- David Piepgrass
- Deepti Gandluri
- Jay Phelps
- Katelyn Gadd
- Lachlan Sneff
- Lars Hansen
- Limin Zhu
- Luke Wagner
- Michael Ferris
- Michael Hablich
- Mike Rourke
- Pat Hickey
- Sven Sauleau
- Sergey Rubanov
- Thomas Trankler
- Ulrik Sorber
- Yury Delendik
Titzer seconds.
No discussion.
Conrad Watt presenting https://drive.google.com/open?id=1d9Gle2mkyLI3_DNF5oytEhUNK0gYg5L8
LW: I like your principled solution, it also matches how we handle the start function, we’re just queuing up something new.
AR: This just turns active segments into syntactic sugar. Perhaps active segments were a design mistake.
BT: Agree.
CW: Is anyone concerned that this may cause errors for programs that were previously rejected?
AR: Only makes previously illegal programs legal. We have to allow such changes in general, otherwise we could never evolve the language.
LW: I doubt this breaks any existing code.
BS: Should this be included in v1?
CW: Change is small.
LW: This is probably bundled with bulk memory operators
AR: I’m fine either way
Sign up for TPAC. Which days are we attending. One day is the plenary day, Wednesday.
Raising the question.
Last time was 2 CG days, 1 WG day.
Day of GC types Host bindings, SIMD, ES module integration
Tuesday, Thursday, Friday
We discussed this initially. Nothing much happened after this. Is there something I can do to move this along? It’s at the hand of the WG to determine what to do here. It is in a state that we need more research on this, perhaps with the spec interpreter or a real implementation. If it adds cost to loading modules then it’s not a win. Aside from whether we can implement this in the spec.
BS: Looking for help?
KG: I can move this forward some, but need help with others if possible.
BT: Karl Schimpf started work on some of this, perhaps that is a place to look.
KG: I’ve seen this, but it is pretty complicated. Perhaps doing something simpler. Making gzip work better. His proposal is very aggressive macro techniques, perhaps even that brotli can’t give you. Do you want to start with something simpler or just use brotli. With my tests, layer 1, bring gzip very close to brotli. But still not as good as brotli, perhaps it’s best to just use brotli. Does this get resolved in the spec repo? From the perspective of someone shipping v8 in chrome, do you want to
[... chair was unable to finish notes, since meeting was going to end abruptly]
Move ahead with only indexeddb serialization for postmessage and message channel.
SA: 0 A: 0 N: 0 F: 9 SF: 0
Discussion: Why not have native wasm threads?
This was originally discussed in the May 2017 meeting, but there are some recent concerns that this may be difficult for non-web embeddings.
LS presenting
LS: working on nebulet. My issue with this proposal, it is not agnostic. Biased toward web. Possible to have ABI to create threads. Splits the ecosystem. Currently you need to create a thread in a worker, you need to call back into JS. I believe PH is doing something non-web wasm, and it seems to create an issue. I know that BS said we want to do this in the future, but I think we need to do this more quickly.
CW: Is there anything that you need outside of the ABI?
LS: I want to run the same wasm on the web, and in nebulet.
AR: I think we all want that eventually, but it may be more difficult than you think. Even ignoring JS, we would need to extend the weak memory model to more than just linear memory. Would need to generalize it to other forms of shared state: globals, tables, references. The current proposal intentionally avoids that as a first step.
LW: I think that a thread.create instruction requires a shared instance, which is complicated. In particular, we have no story for a shared table right now.
Autocad is currently hitting the limit at 100,000.
AZ: They are using emscripten dynamic linking, if they moved to a new system they could use a smaller count. I don’t endorse this use case :)
LW: There are some issues w/ performance here.
AZ: We could use function pointers to do this, but we don’t have it yet. With some work it could be fixed.
JP: Any other issues w/ 1000000 vs. 100000.
LW: They’re both somewhat arbitrary.
SS: Can we increase this to full 32-bit?
BS: No, we want implementations to be aligned on what they can reasonably be expected to allow.
AI(binji): move this discussion to an issue.
AR: there is a slight gap in the JS API now in terms of what import objects one can create. We don’t allow the JS API to generate globals of i64, because of the init value parameter. Since there is a default for that, we could allow creating it, just without an explicit value. You can already create it, but not in a convenient way (by creating a temporary module exporting a global, which is silly).
LW: Can we support exporting functions w/ i64? [SS: it throws] perhaps we should be more lenient here.
[discussion about allowing coercing values to/from i64 for function exports and globals]
LH: If we make it work for globals we should have a general rule.
BS: We may just include this with bigint integration.
AR: This is a slightly different case. Not proposing any new conversion to i64, just allow absence of i64 argument thanks to default value.
N: 1 F: 8 SF: 2
POLL: Include in v1 spec: [spec] Normative: Support [Serializable] for WebAssembly.Module
JP: Some clarification. Didn’t we say we didn’t want this for indexeddb? How does that work for structured clone?
DE: The spec allows you to differentiate between forStorage (indexeddb, history) and not (postMessage).
[unanimous consent]
LS: Shared globals?
LW: It has been discussed. When we ship SAB, then we can talk about shared globals. Then we have GC types, we can have other shared global types. Just like with shared memory, you’d have a shared flag that could be set.