- Where: zoom.us
- When: June 23rd, 4pm-5pm UTC (June 23rd, 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.
- WebAssembly Instrument and Tracing Technology (Richard Winterton)
- Poll: Phase 1
- Advance reference types to phase 4 (Andreas Rossberg)
- Poll on removing type annotation on ref.is_null (issue)
- Poll on advancing to phase 4
- Advance bulk memory operations to phase 4 (Ben Smith)
- Poll on advancing to phase 4
- Advance numeric values in data segments proposal (discussion and semi-formal description repo)
- Poll on general interest in this proposal and advancing to phase 1
- Closure
None
None
- Adam Klein
- Alex Crichton
- Alon Zakai
- Andreas Rossberg
- Arun Purushan
- Ben Titzer
- Christophe Scholliers
- Conrad Watt
- Daniel Hillerstrom
- David Piepgrass
- Deepti Gandluri
- Derek Schuff
- Ezzat Chamudi
- Flaki
- Francis McCabe
- Gergely Buday
- Heejin Ahn
- Ioanna Dimitriou
- Jakob Kummerow
- Jay Phelps
- Jlbirtch
- JP Sugarbroad
- Lars Hansen
- Luke Wagner
- Mano Koukoutos
- Mingqiu Sun
- Mkawalec
- Nabeel Al-Shamma
- Nick Fitzgerald
- Paolo Severini
- Pat Hickey
- Paul Dworzanski
- Peter Penzin
- Richard Winterton
- Rick
- Ross Tate
- Ryan Hunt
- Sabine
- Sabine
- Sam Clegg
- Sam Lindley
- Steve
- Steve Sanderson
- Sven Sauleau
- TatWai Chong
- Thomas Lively
- Till Schneidereit
- Wouter Van Oortmersson
- Yury Delendik
- Zalim
- Zhi An Ng
Richard Winterton seconds
WebAssembly Instrument and Tracing Technology (Richard Winterton)
[Richard Winterton presenting] Slides <TODO: RW to make it link accessible>
RT: What are the semantics of this? How can you reorder this instruction with other instructions? What is the meaning, even if it doesn't have performance implications.
RW: when you see this instruction, you interject into the actual code being generated by the runtime. Usually put it before and after hotspot, so you can narrow down which part of the code is instrumented. You can put it higher, simulator can put it lower, reorder it.
RT: Wasm doesn't have any baked in order of instructions, a compiler doesn't do anything unless it has meaning. It could move it around anywhere.
RW: we ran into that...
KM: should this be considered the same as a call, no re-ordering?
RW: yea. This was optimized away since it wasn’t doing anything. At one point during testing we had to add in a different immediate value to try and not get this optimized away. This needs to be worked out as part of the implementation of runtime.
RT: keith’s suggestion for this as an abstract function call should work.
LH: Atomics also have strong prohibitions against messing with them, so that's possibly another model.
RW: that will work as well
AR: trying to understand this semantic. This behaves like a nop/fence? No observable effect inside the programming model itself.
RW: For the implementation, at least in Intel, we'd need to see a load into the EBX register.
AR: that’s not semantics right? What does this mean? In a portable manner. I’m a producer, emit these instructions, what effects do I expect. If there’s an immediate what does this mean across different platforms. 2nd point is, what can this do that a custom section could not do? E.g. a section that tells you a certain nop is instrumentation.
RW: You could do a custom section with this. It would also work. The only thing I would want is that an end-consumer could use this without having to rebuild the runtime, we could just use the production versions of the runtime. It needs to have a special instruction format in the output, for Intel that's a specific instruction sequence.
AR: in Wasm code, with a certain immediate, you have been discussing this on intel, what about on ARM?
RW: ARM could just do a NOP.
AR: If i Want the instrumentation..
RW: They could do whatever ARM wants with that instruction, they would have to define it.
AR: won’t that you require a platform independent meaning of that immediate, how else can the producer choose what immediate to emit?
RW: THe immediate is just an identifier in a register -- you need an identifier to say start and stop. Imagine you have an inner and outer loop that you want to trace, you can bracket each one independently.
AR: So it's an abstract ID?
RW: yea exactly
TL: It's basically a no-op with platform-dependent modeled side-effects, right?
RW: no-op instruction, something we have to figure out how to, e.g. loading ebx register, make sure nothing is corrupted
RT: So semantically it's an abstract function call (or 16 function calls), but it's important to implement those as a concrete instruction that the target platform knows what to do with it.
TL: we didn’t merge that (intrinsics) into schedule, have to talk about that next time.
BS: no further questions, let’s take a poll
Any objections to unanimous consent? [no objections]
DG: Is ITT a trademark?
RW: good question, need to check
LI: intel lower cases it on their docs, only trademarked intel vtune profiler
RW: whether it’s registered by some other company, i don’t know
Advance reference types to phase 4 (Andreas Rossberg)
AT: Ben Titzer had a comment on the issue last night, can you talk about that?
BT: We split out funcref from externref since they might be implemented differently on different engines. If we have that type annotation on ref.is_null, then the engine knows which value it can compare against. But otherwise it needs information from the operand stack, which is information from validation. We didn't do this in wasm previously, this would be a place we would deviate from that.
AR: i called this out in my presentation last time, this will be a change in the design direction. So far we have the property that every type is self contained. Except we have polymorphic construction (drop and select). This would be somewhat similar, the polymorphism isn’t over a random value type, but over a heap type. The effect is somewhat similar. In both case, the compiler might specialize based on which operand. Diff opcodes on diff CPUs, maybe depending on floats/size of operands. This is not qualitatively new, maybe. The more relevant qns is where we want to move from here. Before we removed subtyping from ref types, we didn’t need to resolve this. But now we have to decide now. I think this is not a property that’s worth maintaining long term. Will have many instructions that will need heavy type annotation. E.g. GC, every instruction will need to annotate type in some way, seems over the top, since you have to look at the type in the validator anyway. If you have annotation, it’s more work since you have to check, and the validator already does that anyway.
RH: I wasn't around for the initial design here -- what was the motivation for having this property initially?
AR: good qns. I don’t really remember. I do remember: we had a discussion about overloading, which we don’t want. E.g. for addition we have different instructions, not just type annotations. The argument here is that semantically they are different. But for this case, it’s uniform behavior, regardless of specific type, even if for implementation you do type specialization, observably it is the same.
BT: In general it was an argument about inference vs. checking, that we should favor being explicit. You mention you can add an annotation in the AST, but an interpreter can't add a place to annotate. In general an engine doesn't always use an AST.
AR: fair point. The design of Wasm has never been in favor of interpreters, not a design goal initially, may be a mistake? Personally I will be fine with this penalty on interpreters. Is this specialization something you would want to do in the first place?
BT: It's conceivable that you might use the type as an index into a table, but you probably wouldn't specialize.
JS: isn’t that equivalent to the validation that we don’t want people to do now?
BT: Imagine that you have two different types that are nullable that have different representations, one 64-bit and one 128-bit for example. Would it have to look at the top of the stack to determine what to do, or what it already know what to do.
JS: but what does the interpreter do if you get drop?
BT: An interpreter typically makes them all the same size, so it knows it can make it generic.
JS: in the case when these instructions have to do extra work, drop also has to do extra work
KM: For drop at least on 64-bit, it doesn't matter.
JS: most interpreters will make null the same, zero value
KM: agree, not super concerned about this too
BT: It depends, you may have an external reference type, the null isn't up to the engine, it's up to the embedding.
JS: i think the point is made, there is a cost
BT: In the future, in general, null is something that comes with the type. So finding which null you're talking about may come with the type. It seems like there's a symmetry we should keep, but it's not the strongest argument.
AR: That was my thinking initially. But there is a fundamental difference between is_null and null. One is a producer, one consumer. Natural that in a linear type checking, you need to annotate producers but not consumers. Something similar will show up in GC, you need to annotate struct.new, you have to know what to produce, but don’t necessarily want to annotate every get.
RT: For overloading in general, it causes problems when you can refine the input type and that changes semantics. That's the difference between ref.null and ref.is_null, with is_null you can look at the input type and determine the output, but for null you have to guess what to produce.
AR: How strongly do you feel about this, Ben?
BT: small change, it is there now right?
AR: we had an informal poll to remove it, no disagreement. The removal of annotation is done in v8 and spidermonkey
BT: i don’t think we should churn again
AR: should we proceed with poll?
JP: on ref types. The assemblyscript folks talked about... we made the rename of anyref to externref in binaryen, but haven’t remove the subtyping relationship. If the tools/languages have not implemented those, and we move to stage4, it feels premature. I would feel better if there are languages that have moved to supported.
JS: right now we just polling to remove type annotations. Not phase4
JP: got it
JS: by consent?
BS: yea sounds reasonable, especially since we had the straw poll 2 weeks ago. Any objections to removing type annotation on ref.is_null?
Poll on removing type annotation on ref.is_null (issue)
[no objections]
Poll passes.
JP: binaryen has not yet done it. No one is using it in the wild. I don’t have evidence of that. On AssemblyScript side, it is a notable change to the AssemblyScript compiler, no limitations now. But feel like phase 4 signals everyone is confident that this is what we want. I don't think we have that signal.
TL: From the binaryen point of view, I wouldn't want to hold up stage 4. It's true that we haven't removed subtyping, but it isn't going to be a big change.
RH: on rust side of things, there is a tool called wasm-bindgen. One of the things is you can introduce anyref on the boundary. That has been updated to support changes. Wasn’t much work since we didn’t rely on that. There is a production tool out there that supports these changes.
JS: did not know that, makes me feel better. No objections if no one else.
KM: what is the toolchain then?
TL: yea wasm-bindgen would count
BS: it was brought up, wasm-bindgen is listed there
AC: has full support, not a ton of benchmarks. Wasm-bindgen is the story for rust and reference types
KM: wasn’t trying to dispute
AC: yea, just clarifying
BS: Any questions about phase 4 toolchain requirements? Or any other questions? We discussed before that we have all the requirements necessary, let’s poll.
Poll:
| SF | F | N | A | SA |
|---|---|---|---|---|
| 22 | 18 | 5 | 0 | 0 |
AR: thanks!
Reference types advances to phase 4 :party: Congratulations AR!
Advance bulk memory operations to phase 4 (Ben Smith)
BS: ref types and bulk memory are interlinked in a lot of ways. Advancing ref types since it is dependent on bulk memory kinda means we have to advance it anyway. Any questions or issues?
TL: only memory part implemented, table instructions are not
HA: wasm-bindgen?
TL: I am not concerned about whether we implemented enough. But no toolchain uses table instructions. I don’t think wasm-bindgen uses the bulk table instructions
BS: similarly there is not table.get table.set uses
NF: wasm-bindgen will use those, rewrites the binary after llvm
BS: question is, which instructions are being used. If they are being used by ref types, it’s a question of specific instr, table.init and table.copy
NF: table.set get grow, only use.
AC: we are not using table.copy and init
JS: pretty sure binaryen has implemented this
TL: Binaryen doesn’t fully implement it yet, we have plenty of toolchains that implement half of it, personally not against moving this forward, but wanted to point out that it’s not fully implemented
JS: i think i’m still okay with it
AR: some of the table bulk instructions ended up there
BS: only one is table.fill
AR: grow as well
BS: discussed, table.fill moved to ref types, requires a ref as a value to fill. There is a qns about that, is it required that tools use all instructions from the set? Seems like a strong requirement, some tools will not need. Perhaps we should revisit in 2 weeks, and have a larger discussion.
JS: We wanted a toolchain that allowed - advancing to phase 4 means that toolchain has them, and we can experiment with them.
KM: some concerns in the sense that... it will be weird to have these requirements and not follow them. For JS standards it’s a bit different, we have requirements, and those are valid reasons to object/block. It’s consensus. I’m just strawmanning this. If someone cares, and blocks it. This can be a precedent
HA: even if we go back and implement these instructions, then we are not going to use it in the near future, no use case. Not sure if implementing it is any different from not having it.
NF: Wams bind-gen is in the same place, as a user facing tool, it doesn’t need them right away which is why it doesn’t have them.
RT: meta-concern, why are we adding instructions that no one needs?
BS: let’s pause this, we have 1 minute left. Seems to me like agreement - most people not willing to hold up, but we are concerned. We should have a separate discussion about this topic. Let’s plan to have a discussion in 2 weeks time. Can get agreement that no concerns about it.
[Room agrees]
AR: Also worth pointing out, that it’s recursively dependent proposals for bulk memory, reference types mean that we can’t land one without the other
BS: Lots of SFs before this discussion, so would like to move this forward, if anyone objects please voice your concern.
[No objections from room]
BS: Will be taking this as interest to move the proposal forward
Poll: SF: 21 [poll cut short due to above discussions] F: N: A: SA:
Advance numeric values in data segments proposal (discussion and semi-formal description repo)
BS: poll from 2 weeks go
Consensus poll: Consensus. Congratulations to echamudi@!