- Where: zoom.us
- When: September 27th, 4pm-5pm UTC (September 27th, 9am-10am Pacific 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
- Update on Stack Switching (Francis McCabe) [1Hr]
- Closure
None
None
- Daniel Hillerström
- Yuri Iozzelli
- Conrad Watt
- Derek Schuff
- Rick Battagline
- Sean Jensen-Grey
- Benjamin Titzer
- Francis McCabe
- Sam Lindley
- Nick Fitzgerald
- Paolo Severini
- Ilya Rezvov
- Chris Woods
- Ross Tate
- Emanuel Ziegler
- Alex Crichton
- Alon Zakai
- Chris Woods
- Steven Prine
- Thomas Lively
- Justin Michaud
- Ashley Nelson
- Andrew Brown
- Adam Klein
- Slava Kuzmich
- Luke Wagner
- Asumu Takikawa
- Manos Koukoutos
- Mossaka (Joe)
- Matthias Liedtke
- Brendan Dahl
- Sean Westfall
- Richard Winterton
- Petr Penzin
- Krisztian Gacsal
- Andrew Brown
- Zalim Bashorov
- Dmitry
- Kevin Moore
- David Piepgrass
- Shravan Narayan
FM Presenting slides.
SL: Point out that you’re presenting one particular proposal, there’s two proposals active - one of them is called typed continuations, and has some prototype implementations, this is not the only proposal in flight.
FM: I’ll be addressing that at the end of the presentation.
RT: One other team that’s been very involved - the Erlang team. They were helpful with informing the usage model, which is switching is immediate, or the yielding is voluntary and the target is determined by running a scheduling function on the current stack.
SL (chat): The typed continuations proposal was deliberately designed to avoid the need for GC
BT (chat): IIRC implementing a generator with the typed continuation proposal requires creating garbage?
SL (chat): I don't think so... but some form of reference counting is needed.
RT: One useful aspect of that is, similar to WasmK, you can have a table that’s just a fiber reference table, so it becomes simpler for applications
RT: For those interested, I can walk through how to implement this without boxing
<Slide: Compared to typed continuations>
FM: Typed continuations is another approach for this, a sort of functional-programming way
SL: IMO typed continuations have nothing to do with functions and make sense in an imperative setting as well.
CW: You mentioned in an earlier slide, Source languages want to optimize for many suspension points that are not used. When you talk about GC pressure is it per suspension point?
FM: In the fibers model the GC pressure is per prompt point, potential suspension point. With continuations every time you suspend you have additional allocation independent of that. IN both cases you have places you might suspend to and places you actually suspend. You have potential pressure in both places, but in typed continuations you get allocation when you suspend.
SL: Could you explain what you mean by not compatible with uniform representations?
FM: For generic representations, you have a pointer for each generic value RT: the bullet point means that the fix to reducing the GC pressure isn’t compatible with uniform representation. E.g similarly with anyref, the fix is to have wide references, but that’s not compatible with uniform either
CW: We decided to split out Funcs, to support non-uniform representations, so this seems to be compatible with that
SL: I think there are other solutions to this, we should discuss more offline.
CW: It seems to me that the extent to which handlers are identified statically/dynamically seem uniform across the proposals, at least at a per-frame level. In what way is typed continuations more dynamic?
FM: the fiber proposal isn’t dynamically scoped at all. When you suspend, you suspend a particular fiber and there’s one “hop”, the resume parent (the last resumer of the fiber) must have a handler for the suspension so there’s no search. With dynamically scoped continuations you have to do an EH-style walk up the stack to find the handler. Sam will say that there’s a variation in typed continuations where you can label the handler in an analogous way, but there’s other issues: unwanted capture is one. It also makes it difficult when you’re crossing components/ownership boundaries you have to do a lot of work to make sure that the other component outside your ownership doesn't have access to your scope, it’s a problem with “ambient capability”
SL: Whether you use dynamic scoping or not is completely orthogonal to whether you use typed continuations or the Fiber based model.
FM: that’s true
RT: It’s a signal of a nice reusable thing. The only thing we don’t support is multi-shot continuations. Everything else we support the same way they would have done natively.
FM: The potential benefits of implementing multi-shot continuations doesn’t justify the investment at this time
BT: A vote doesn’t seem to be the right way to resolve this, are there other objective other criteria that we can resolve here?
SL: I don’t think we’re ready for a vote anyway, we need to resolve certain technical issues.
CW: my only comment given how this presentation has gone, it’s not enough just to say that one proposal satisfies the stakeholder needs, we need to compare them directly
SL: Viewing as two competing proposals is not helpful, we should explore this as a design discussion, and explore the problem space - it’s more a question of what are the features that are most important to have. The other thing we’re doing that i think will be helpful is that we’re implementing typed continuations in wasmtime. Then we can do some experiments and benchmarks and get some evidence to show what works better rather than hand waving. But that won’t happen immediately. So I'd suggest it would be better to make a bit more progress on that before deciding and committing.
DP (chat): I ♥ stack switching
LW (chat): I'd also like to see the two proposals to converge
BT (chat): +1, especially in terms of terminology and naming
NF (chat): +1
FM: I’m happy that SL mentioned that they’re not that far apart, there are definitely qualitatively different to get over. As far as the vote has concerned, it may slightly seem premature to move to a vote soon. However the engineering resources devoting to this, and it risks going away if we lose momentum, that’s the biggest risk.