- Where: zoom.us
- When: March 31st, 4pm-5pm UTC (March 31st, 9am-10am Pacific Daylight 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.
- Form a garbage collection subgroup (Andreas Rossberg), proposed charter
- Move custom annotations to Phase 3 (Andreas Rossberg)
- also, discuss Phase 4 criteria, since this does not affect engines
- Discuss: should funcref be a subtype of anyref
- Discuss global ref.func initializers complicating validation (reference-types issue#76)
- Move bulk instructions and reference types to Phase 4 (Andreas Rossberg)
- Discuss removing the maximum initial memory size restriction.
- Closure
None
None
Conrad Watt
Arun Purushan
Deepti Gandluri
Ben Smith
Ryan Hunt
Francis McCabe
Lars Hansen
Paolo Severini
Rick
Wouter Van Oortmerssen
Nick Fitzgerald
Dan Gohman
Derek Schuff
Mitch Moore
Zalim Bashorov
Jkummerow
Ben Smith
Keith miller
Alon Zakaii
Rich Winterton
Zhi An Ng
Nabeel Al-Shamma
Sean Jensen-Grey
Andreas Rossberg
Heejin Ahn
Sam Clegg
Adam Klein
Emanuel Zeigler
Ross Tate
Thomas Lively
JP Sugarbroad
Tatwai Chong
Yury Delendik
Alex Crichton
Ingvar Stepanyan
Thomas Trankler
Lars Hansen seconds
AZ: Lars asked to only allow growing about 2Gib to reduce compat issues. You wouldn't be able to start with 3 or 4 Gigs, but would have to grow to it. Seems like an arbitrary limit, would complicate testing. Lars seems to be OK with removing the limit. I'm proposing allowing up to 4Gb of memory normally. Just allow that. Some risk of compat, but user would have to request explicitly. If they ask and don't need it, it probably won't run in a lot of places anyway. Seems unlikely that user will do it unintentionally. Thoughts?
LH: FWIW, I still don't like it, but I've stopped objecting to it because I don't think it's a battle I think I can win.
AZ: Happy to talk more about it, there’s probably a risk that you see more than i do, happy to talk about it
LH: no need to talk more, we have to be done with it
JG: Should we have a protocol for allocating memory, host and wasm module can negotiate for memory. Is there a place for a protocol for this?
AZ: I don’t have a good idea for a protocol - in general if they know they need some amount of memory - the game will ask for 3G, and not work if the memory isn’t available - we start with an initial memory and grow
Form a garbage collection subgroup (Andreas Rossberg), proposed charter
AR: do we have a procedure for forming a subgroup? Most people already saw the chart for the group, think it’s fine. Let’s just land that? What remains is to find a good time to meet regularly. How do other subgroups organize? Bi-weekly? Case-by-case?
DG: I think it's been organic to what a group needs. So discussing offline is best.
AR: for these meetings,we have agendas in meetings repo, but not for subgroups. Is meetings repository the right place for subgroup meetings notes and agendas?
DS: for debugging and wasi, they have their own repo, mirrors the spec repo, separate folder for notes
AR: what happens when you merge into spec repo?
DS: For debugging, for WASI too, there’s not a spec that’s not intended to be merged
AR: for gc subgroup, we have the gc proposal, might be wrong place to put meeting notes
DS: separate repo for the subgroup just to put notes, one spec fork per proposal
AR: so many repos, why not reuse the meetings repo. Do people think it’s okay?
DG: no objection
AR: You don’t get a good picture of the where the notes are, if you don’t archive them or have them somewhere centrally
DS: separating issues, subgroup related issues will end up in meetings repo, strange?
RT: We could always discuss this was meeting, and point to the meeting notes so it’s discoverable.
FGM: structure the product of the group itself - e.g. criteria questions, design question, more than 1 piece of documentation. Think about not just during the group, what about after the group is done - how does someone know what is important, how to navigate?
DG: i will open an issue on GH repo to discuss this more
Move custom annotations to Phase 3 (Andreas Rossberg)
AR: At the f2f we decided to move to phase 2, but we didn't want to jump phases. There's one issue, renaming @custom to @customSection, but minor thing. Wondering if we should move to phase 3, since requirements were already met at f2f meeting.
DG: Maybe just unanimous consent? Anybody object, or have concerns about proposal? [silence]
Custom annotation proposal moves to phase 3.
AR: Our process criteria talks about engines, but this is one of the first proposals that has no implications on the engines - what are the requirements for moving this to phase 4? Should we talk about tools - should more than one toolchain implement this?
DS: think it make sense, should have 2 different code bases implement this (similar to web engine). What criteria should be analogous to “web vm”, don’t feel strongly about this criteria
AR: If Binaryen and Wabt implement it, would that be enough?
DS: yea, would think so. They are different enough. Firefox wat format perhaps [BS mentioned this in chat].
AR: If we lanbide it in the spec, we should probably support it
LW: Browser doesn’t support it, but the shell does/should?
RH: rust crate called wat (?), supports text format, used in shell testing, probably supports custom annotations already
AR: question for other folks in binaryen and wabt, LMK when yall implement it, so I know it’s time to move to next stage
AR: open issue discussed at f2f meeting, number of threads + discussions between various people. We don’t have unanimous agreement, but most feel that we should move ahead with what we have. We can discuss all the details again ?! Mainly, Ross doesn’t like it.
Why To Remove Subtyping Slides (pdf) (pptx)
RT: for months, no established uses cases
AR: I would disagree w/ no existing use cases. Biggest one is that we need something like this for type imports, and for closures for func.bind. If you want to use them in the uniform representation, you'd need that.
RT: We can discuss those use cases, for func refs, every language expects equality except Haskell, but your func ref proposal doesn’t address it - good to address this ahead of time in the issue that asked for use cases, also type imports..
AR: The point is that, if you do that you put the same constraint on the type. For the type import to work, it needs the same uniform representation.
RT: This says removing subtyping, that’s one of the 6 points on here - use cases for the actual subtyping neither of those are necessary
AR: The primary purpose of anyref isn't for external references. We discovered that it was a relevant use case, so we pulled it out into a separate proposal. If we thought it was for external references we wouldn't have called it anyref.
RT: Reason why everyone wants this right now, is this purpose?
AR: assume you are alluding to your paper, that is heavily geared towards single inheritance, class-based
RT: I worked through a number of languages, it works for OCaml, java, C#, ...
AR: If you encode everything as objects..
RT: No, ... we haven't worked through any other system to know how it will work. So if we rule this system out, we don't know if it is even applicable. If we rule it out, then we have no options.
LW: Is this about ref.null? [RT: yes] IS that the specific problem? What you want is that this would run before wasm compilation?
RT: The way this technique works -- browsers don't do inference. The languages that use wasm do... the keyword here is practical. To eliminate casts, we need fancier types. It is much fancier than we've seen in any proposal so far. So we'd need all tools to support these fancier types.
LW: Three would be a different language? And there would be a different explicit inference step?
RT: For this ... we took an additional C# compiler and tacked on the inference. It makes it a tack-onable library that you can add to an existing compiler.
LW: Input to inference isn’t wasm, it’s pre-wasm right? Something that’s type annotated
RT: We gave it x86 -- the point is that your compiler would need.... if there is anything that is above wasm, you'll need another language above that.
LW: That’s already the technique you’re describing, at places you would have to have done an inference type because of explicit blocks - there’s a version of wasm where you have lesser type inference, and then something that’s more complete wasm
RT: The practicality right now is that the types are simple. If we do this otherwise, we need a much more advanced system. The previous work here required 7 phds. Nobody knows how to make this work, so it would require completely new work.
LW: That would happen before producing Wasm..
RT: You'd produce wasm without types, yes.
AR: This is definitely out of scope for what the engine will be able to handle
RT: The engine would not be doing any inference, right.
TL: I still care about practicality as a tool author, just because it’s not in the engine doesn’t mean we shouldn’t talk about it..
RT: The idea would be... you can write your tools without types, then the tools create types, and the engine can use those types.
JP: Can you help us understand what the cost is to eliminating the subtype - we have a discussion to include it or not? Why can’t we include it later? That doesn’t seem to be an option
RT: That certainly is an option. We can add it later. The problem is that there is code implemented there that uses it.
AR: I can quantify how big a change that is - it’s not exactly time, has implications on other design aspects - for the repo the diff is 600+ lines included tests. That was a change to remove the subtyping - that’s absolutely minimum change - just for removing - if it’s for the whole proposal it’ll be 100s of lines - what’s worse is the impact of this on other proposals which is poorly understood.
RT: I'm removing subtyping from the current proposal because it's the wrong subtyping.
AR: We’re back to the discussion in the same two months - because the next proposal also has subtyping - like Func refs. You can’t get rid of that then other things will break, or you can’t explain the things
JP: Nobody is proposing banning subtyping...
RT: I’m not..
AR: You probably have some different notion of subtyping in mind that would require us to redo our proposals. I'm not sure how long it will take, or what the benefit would be. It feels like a very fundamental and late change in the process. We will need to re-evaluate everything downstream. Doing it now seems like a very bad idea. The other question is what is the benefit -- you brought up a few points, but I'm not sure I agree with them.
AR: You want different representations, for type imports, you don’t want to commit to what type of representations are behind that.. That’s the same case for Anyref too...
JP: In the GH issue, it was proposed that instead of funcref and anyref, you can have boxing and unboxing operators. An explicit cast to have the underlying embedder to compile different representations.
AR: Because then you have to allocate all over the place, it would work, for example you can’t use a closure - you have to box/unbox
JP: You don't have to box and unbox, you have the option to do so. Your implementation could have it as a no-op.
AR: If you’re only talking about the host, you can do type imports from other wasm modules...
JP: But even if you type-import from other modules, then the thing compiling the code could use compatible representations, then they can use it with a no-op. If we find that all of the implementations use the same reps then we could add the subtyping later.
AR: You have to add the coersions to the language, and every language that uses these will have to add them...
RT: Currently I haven't seen a plan that shows how to compile a language to this road-map. I haven't seen this at all.
AR: There are parts of the roadmap that are clear, and the rest that are unclear.. Parts with GC are less clear
RT: You said that functional languages will use funcrefs for their closures, but they require equality so they can't use that.
AR: Minor detail, that’s not true
RT: OK, but many many languages can't do that.
AR: We left out equality of func refs..
AR: When you have type imports you want to be able to import something without knowing what it is. What do you base the restrictions on? If you don't know what people want to import as types, then you should not impose restrictions there. We don't want to impose restrictions prematurely.
RT: What restrictions are we imposing prematurely?
AR: If you say that certain types can't be used as a type import th
JP: We are talking about certain types being explicitly blocked, at the same time there are restrictions on both sides
RT: Many languages can have the assumption… same bitwidth that’s really all you need
AR: IF you need something changeable, you need these to be interchangeable - you may need to differentiate in code whether this is tagged or not
RT: You're talking about GC and cross ... you need a bit-width and a convention about how to collect that value. It still doesn't need uniform representation. There are descriptor modes, ...
AR: Descriptors makes everything more complicated. There doesn't have to be any magic that is passed under the hood... [RT: I didn't say that] You need to pass the descriptor, then you're in reified generics territory.
RT: Import/export doesn’t need...
AR: Useful to have subtyping against the bound, ...
JP: Another question, w.r..t coercion. the host that has to typecheck. In the face of subtyping, it needs to know where the subtyping is required, why can't it insert the coercions implicitly?
RT: Right now, in the code we’re talking with you could do that - the problem is when you use it recursively in a signature you have covariance and contravariance w.r.t. The signatures - there there’s no coercion going on there (Explains with an example) Where you wan subtyping is where you want covariance and contravariance.
JP: This subtyping relation makes call complicated in the face of different representations, is that what you're saying?
AR: It makes things simpler as long as you use a uniform representation. All engines do this already. There are very few runtimes that use non-uniform reps currently. You argue that we can add this later -- but that cuts both ways, we could add raw type later too. If you have that type, we need the boxed type later anyway. We can't box and unbox anywhere, we need a type for that too. We need to double the type algebra already.
JP: If they don’t need to be compatible with anyref, they don’t have to box the types - the embedder can augment the types - we’ve talked about being able to represent
AR: In a way this boils down to having two different types of function types, which one should we do first. I'm saying we should have boxed ones. I don't see a practical world where we only have unboxed ones.
JP: The proposal is creating a two funcrefs, one that is a subtype of anyref and another is not.
DG: have an off-cadence meeting to discuss just this and make a decision there
JP: I would like to see on a straw poll basis to see if we have any consensus here.
LW: I think we could have maximally conservative position, to not commit to either perspective. But 5 months from now we can determine whether it is appropriate to do so.
AR: IT’s not conservative, you actually have to use subtyping or change the design
LW: It’s in a way that doesn’t change, just adds some waste
RT: most of the burden is on the spec, comment out code and return is_equals
HA: toolchain changes required too
AR: I think the minimal thing is not currently tiny... it may require 1000 lines in the spec.
JS: sounds like - carve off a piece of this, funref subtype, into downstream proposal, unblock ability to have external ref types
AR: I understand that, but it's not a small change to the proposal. It affects other proposals with unclear changes.
JS: we can discuss this in the next proposal
AR: we have to change existing proposals to take this out.
JS: We can defer those downstream changes until...
AR: have to change instruction sets
DG: let’s stop this, will file and issue to find a timing that works, set up a diff meeting just to talk about subtyping, outside of this CG
AR: doubt we can make any more progress than we have today, or over past period
DG: let’s give it a try, does it make sense to do a poll for bulk memory proposal
AR: nope, doesn’t make sense, bulk memory proposal depends on this subtyping decision, so we cannot advance that
DG: I will find another time for the next meeting. We're exactly at time, going to cut it off now.