- Where: zoom.us
- When: January 22, 5pm-6pm UTC (January 22, 9am-10am Pacific Time)
- Location: link on calendar invite
- Contact:
- Name: Ben Smith
- Email: binji@google.com
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.
- Coordinate encodings between bulk memory and reftype proposals
- WebAssembly SIMD issues triage meeting on 01/23/2019, at 2:00PM PST. Fill this form to be emailed a link to the meeting.
- js-api updates
- inconsistent utf-8 decoding follow up; a PR is available.
- Please review update limits.any.js and sync wasm-module-builder.
- Split typed function references from GC into their own proposal.
- Closure
None
None
- Adam Klein
- Alex Crichton
- Andreas Rossberg
- Arun Purushan
- Ben Smith
- Conrad Watt
- Daniel Ehrenberg
- Deepti Gandluri
- Francis McCabe
- Gus Caplan
- Heejin Ahn
- Jacob Gravelle
- Jensen Grey
- Keith Miller
- Lars Hansen
- Limin Zhu
- Luke Wagner
- Richard Winterton
- Sven Sauleau
- Thays Grazia
- Thomas Lively
- Yury Delendik
BS takes notes.
Lars seconds
LH: two things here. We're not making a lot of progress on bulk memory. Reftypes proposal has ideas about encodings, it has multiple tables and so on. It makes assumptions about encodings so we need to decide soon.
BS: Seems like we've aligned behind two bytes instead of a flag byte.
...
BS: What are the other things we need to decide now?
LH: Table.fill? Should we assume this will land at the same time.
AR: One or two of the instructions need to be spec'd as well. Then they will reference the ref types.
BS: Concern about creating a prereq chain.
LH: We assumed feature testing. Could ship bulk tables without bulk tables.
BS: May have issues with tooling and such.
AR: Hard to use a feature without all browsers already. Recommend not using till everyone has it. Don't recommend feature testing.
DE: I think it's a real danger that we could end up in elaborate feature testing paths. In JS we've seen this. I try to encourage people in JS shipping features as a whole. Has been hard to do this, seems like an OK pragmatic path.
AR: I hope that we can't compare JS w/ wasm here, because it's user-facing, and regarding libraries. For Wasm it's most interesting w/ features that you can't emulate at all, but then feature test doesn’t help.
DE: Hope you're right, but we've seen this in tools. This had concrete compat impacts.
BS: w.r.t. splitting bulk memory out from bulk table.
AR: No concerns.
DE: Most important that MDN and browser compat info is documented properly. Don't worry about proposal repos.
AR: One comment; the most important thing is when we move to phase 4. Shipping in phase 3 means users have to be careful.
- Some comments about shipping phase 3 vs phase 4 *
WebAssembly SIMD issues triage meeting on 01/23/2019, at 2:00PM PST. Fill this form to be emailed a link to the meeting.
DG: There's going to be a meeting to triage the SIMD issues. We want to bring things up, and move it forward. There's a form that's linked.
- inconsistent utf-8 decoding follow up; a PR is available.
- Please review update limits.any.js and sync wasm-module-builder.
SS: utf-8 decoding between section names and API. Creates mismatch between surrogates. Have PR that switches from UVString to DOMString. We cannot normalize surrogates anymore. It would be nice if someone can review it.
BS: Probably best for Dan or ms2ger to review.
SS: I have updated the limits tests, I want to synchronize the wasm-module-builder in v8 w/ spec repo.
BS: Sounds like we just need to review and merge.
Split typed function references from GC into their own proposal.
AR: We've discussed this a few times before. There's a link here; copying out function references from the GC into its own repo. That contains function references, forming a reference, calling a reference, and func.bind creating a closure.
New block type that introduces new locals (let). Because refs don't have a default value.
One open Q: whether optional refs should be part of that proposal. How relevant is not clear to me. Some bikeshedding about names.
LH: Were you thinking about advancing more quickly than GC?
AR: Yes, that's the idea.
DE: Are the browsers interested in shipping this proposal?
AR: Maybe Lars?
LH: not committing to this yet, but think it's interesting.
AR: func.bind is the most controversial part, because it's a closure. If that’s an obstacle we might want to separate it
LW: Already kinda is a closure, because they close over the instance.
AR: Hope is that it isn't a significant extra cost as a result.
BS: Unanimous consent?
FM: Can't do closures without GC...
AR: They already are closures -- in a fully static setting you might imagine that instantiation is static, then a function pointer is more expensive.
LW: I think that you could do ref counting instead here.
FM: How will these be stored? In a table?
AR: This builds on top of ref type proposal, so yes.
FM: This is an issue for languages ... that need to put a closure in an object.
AR: You need to create an indirection, store a table index in linear memory.
FM: I'm not sure you can do that.
AR: We're already doing this; you can ref count if you don't want to use full GC. It's more awkward to use than GC types of course, but this is meant to be an intermediate thing.
One example: if you want to communicate a function from one language to another you can't do this with in-memory-closures; you need this to be built in.
FM: The closure needs an environment. Does this have a standard layout?
AR: No, it's completely opaque.
FM: So you need to call, is that in the proposal?
AR: Yes call.ref.
FM: Need to have the function and environment...
AR: The engine has its own heap that you can't access. In current engines that is identical to the JS heap. In standalone engines they'll also already have their own heap somehow. They'll have to manage memory for various instances.
FM: Seems an awkward representation.
LH: Why is that?
FM: If I'm implementing closures, it's an n+2 record, size, code, ...
AR: In reality, with your own closure in linear memory, you have a record n+1, code pointer really is a pointer to another heap object, which has the pointer to the actual code and its module instance. This proposal allows to merge these records.
FM: I didn't see this [AR: sorry, it's new from a day ago].
AI(BS): Discuss this in the next meeting.
DE: Related question about splitting proposals. I was wondering about the array types in the GC proposal. But made a bug item instead.