- Where: zoom.us
- When: April 28th, 4pm-5pm UTC (April 28th, 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.
- Safety in the WebAssembly C API. [Slides](c-api slides)
See WebAssembly/wasm-c-api#132 for background.
Poll: Should wasm-c-api pursue safety, as discussed in this issue?
Poll: If not, approve a new WebAssembly C API proposal at phase 0? - Flexible vectors - slides, design/1332. Poll: Approve phase 0 for flexible vectors.
- Poll: Propose WebAssembly BigInt<->i64 conversion in JS API for phase 4.
- Poll: Remove subtyping from the Anyref proposal.
Context: WebAssembly/reference-types#69.
Meeting notes from off cadence meetings: 04/02/2020, 04/21/2020
- Closure
None
None
Manos Koukoutos
Ms2ger
Deepti Gandluri
Thomas Lively
Francis McCabe
Nick Fitzgerald
Ben Smith
Jay Phelps
Rick
Ryan Hunt
Derek Schuff
Sabine
Petr Penzn
Lars Hansen
Sven Sauleau
Dan Gohman
Jacob Mischka
Luke Wagner
Keith Miller
Yury Delendik
Zalim
Jakob Kummerow
Alon Zakai
Alex Chischton
Zhi An Ng
Nabeel Alshamma
Ross Tate
Conrad Watt
Rich Winterton
Heejin Ahn
Emanuel Krivoy
Tobias Tebbi
Andreas Rossberg
Adam Klein
Emanuel Ziegler
TatWai Chong
Ingvar Stepanyan
Luke Imhoff
Arun Purushan
Ioanna Dimitriou
Wouter Van Oortmerssen
JP Sugarbroad
Ioanna Dimitriou
Jensen-Grey
Ben Smith Seconds
DG presenting [c-api slides] (https://github.com/WebAssembly/meetings/blob/master/main/2020/presentations/2020-04-28-gohman-c-api-safety.pdf)
RT: What's the trust model here?
DG: IF you look at the JS-API - that’s a good model for it - you can’t modify any key aspects of the module - the things that are impossible to modify at runtime are the same invariants that we are enforcing here.
RT: My question is: you're trusting the C API program implicitly? Not a separation of trust. Just curious if you're trying to solve a harder problem here.
DG: When you’re talking about C code, it’s unsafe, the untrusted parts are the module, the C code itself is assumed to be safe, the wasm module is supposed to be unsafe - if you’re expecting an immutable global in the C API, but the module defines it as immutable then you want that error to be defined, similarly with exports..
RT: Second question. What's the substitutability model here. If you have a well-implemented engine and another, how reasonable is it to get exactly the same behavior between the two?
DG: If you use the unchecked APIs, no guarantees they have undefined behavior, if you dont… we haven’t finished the work of verifying the entire API yet, but the goal is to ensure compatibility between well implemented engines
AR: Primary goal of C API is that people don't program in it directly, it's a binding API. So it should be low overhead. C is fundamentally an unsafe language, some of the cost of performance is that it is unsafe. We can find middle ground there. The best you can do normally is adding assertions. Best you can do is sanity checks, I think there are things that you think that can be checkable that cannot be checked. These are checks that are asserting preconditions to the API...
DG: Can you clarify what you mean by things you can’t check? The JS API can check most things, what are things that the JS API can check and we can’t check?
AR: I think that we can still do this in the JS API because it's still a simple language, I think in the future we may have to make the JS API more complex or not check things. The other issue is that it requires self-reflection to implement.
AR: The status of these checks is like assertions, and people usually want to tuern them off. In some environments it’s common practice to turn assertions - we require checks.. And they have completely undefined behavior that’s not ideal - it’s the nature of the low level API. Having a checked/unchecked API is not the solution to this - you want to be able to have just one switch when going to production, it’s not the right level that you want to do this at. The specification/semantics should not enforce hecks. It’s good if implementations provide checking, it shouldn’t be a required part that when you turn off implies undefined behavior, it’s not what you want to specify. Not necessarily about having different goals - but where you put having different requirements. If you put it in the API spec, then you throw out some usability - that would not be good - because you want to have the correct semantics. The checked/unchecked versions you want to specify what that means because some undefined behavior becomes defined behavior.
AR: The last thing I want to say. The things you're adding are protecting against bugs in the host. The kind of error reporting you want to do, you should distinguish that. There's a difference between the wasm program itself that has an error and the host having an error.
LW: There’s a bunch of checks if they are not optionally done in the C-API then they have to be done by every host - if it’s well defined and donbe, then the host can rely on the C API to perform these checks. Maybe I want all the checks except the one on the really hot path. Incidentally the C API isn’t good for hot paths, there’s more work to be done apart from tearing out the checks.. But there’s a commonality between the host
AR: I can agree with that. I'm less sure about the factoring. Another problem w/ check vs. unchecked cases, the cost is not in the call. The cost is based on having additional data stored...
LW: If it’s all defined in the JS API, it’s a precondition that’s already defined..
AR: I think this will only get you so far, though. Some of these are possible because the language is simple. Currently there is no complex objects...
LW: Let’s cross that bridge when we get there, because the JS API will also need that..
AR: Does this mean we're painting ourselves into a corner?
LW: It’ll be symmetric with what we’ll do with the JS API..
DG: JS API, Python, Ruby, they'll all have the same problem here. We'll have unchecked for hot paths when needed.
AR: My point is, this is something you need to configure statically, you’re paying for the overhead, you have to compile the engine with a different configuration..
DG: One thing I want to address. We don't look at these like assertions. If you're a high-level language you need to have it. If you need to have it in your bindings, then each of them have to do it. This is required to make your high-level language work.
LW: If we get to this point, when we get to the expensive situation, we can have both.. We can cross the bridge when we get to it
DG: If you're using it from high-level bindings,..
RT: Historical example, is the simcity example, when windows 98 wanted to upgrade something.. Some part of the API was undefined, and not enforced by checks, when they wanted to upgrade, turned out to be incompatible with simcity, Conditional on if(simcity) do this unchecked behavior, otherwise do this behavior, which was not what was intended, but happens in practice
AR: There's one other assertion you made. All bindings will have to implement these checks. Some other languages will enforce these properties with type systems. You'll make them pay for this.
DG: Unchecked APIs can be proved to be safe..
LW: IS that the only thing though? How do we express uncheckedness? The only thing left to figure out how to opt out of the checks?
AR: One is how to opt out, the other is how to import them.. It’s not really a trap, we should report it as a different thing that can be defined, the other is how do we opt in/out. We specify the preconditions, and then say that there are some ways to check some preconditions but not all
DG: If you can't check all of them, then you can't have a JS API.
AR: The JS API may be more restricted, why would you hold everyone hostage to what the JS API does?
DG: Poll is: should the wasm C API, accept the PR as laid out...
AR: Poll is too binary
DG: Happy to work through details there, trying to get a clarity of direction..
AR: You haven’t motivated why these changes are required?
Poll: Should wasm-c-api pursue safety, as discussed in this issue?
| SF | F | N | A | SA |
|---|---|---|---|---|
| 6 | 10 | 18 | 2 | 0 |
BS: Seems pretty clear that the group agrees that there is consensus on having safety..
AR: The way that it’s currently done in the PR is.. I want to ensure that we have a toggle that still has the defined semantics -
DG: I think we fundamentally disagree here..
BS: We can get to the point where we have to figure out what the semantics are, that sounds like a reasonable compromise.
<More discussion DG, LW, AR - taking it offline>
Flexible vectors slides, design/1332. Poll: Approve phase 0 for flexible vectors.
PP: presenting
AR: One basic question: you're proposing introducing implementation-dependent behavior to wasm?
PP: Depends on what you mean by implementation dependent?
RT: Doesn’t length change on each implementation?
PP: Yes, the vector can change on cell phone, desktop, etc.
TL: Vector length itself is implementation defined..
PP: Machine code you’re generating changes though
TL: The code you're intended to generate would not have observable differences, but using this proposal you could construct an example that has different behavior on each platform, for example returning the size of the vector.
AR: The number of
DG: There are definitely implementation-defined aspects. Other implementations don't have to have the maximum length. The poll that Petr is putting in is for phase 0/1. Not set in stone, mostly investigative.
KM: Is the reason why this is better... it makes code generation easier, since your loop can be dependent on what the machine supports?
PP: Yeah, generally because you would have to.. We don’t actually combine them
KM: You could do a loop invariant strength reduction, there are loops you can write that you don’t have to flatten it out..
AR: Similar concern as KM
JS: Consensus requirements are low: do members believe that the feature is in-scope will be workable.
Conclusion: Unanimous consent for Phase 1, with caveats that there are design concerns that need to be discussed.
Poll: Remove subtyping from the anyref proposal
| SF | F | N | A | SA |
|---|---|---|---|---|
| 7 | 9 | 8 | 2 | 5 |