CG-08-27.md
April 21, 2025 · View on GitHub
Agenda for the August 27th video call of WebAssembly's Community Group
- Where: Virtual meeting
- When: 2024-08-27, 16:00-17:00 UTC (2024-08-27, 9am-10am PDT, 18:00-19:00 CEST)
- Location: link on W3C calendar or Google Calendar invitation
Registration
No registration is required for VC meetings. The meeting is open to CG members only.
Agenda items
- Opening
- Proposals and discussions
- Unified approach to stack switching (Sam Lindley & Francis McCabe, 45 minutes)
- Vote for phase 2
- JS String Builtins: vote for Phase 4 (Ryan Hunt & Adam Klein, 15 minutes)
- Unified approach to stack switching (Sam Lindley & Francis McCabe, 45 minutes)
- Closure
Agenda items for future meetings
None
Meeting Notes
Attendees
- Francis McCabe
- Thomas Lively
- Derek Schuff
- Daniel Hillerström
- Conrad Watt
- Paul Dennis
- Yuri Delendik
- Ryan Hunt
- Brendan Dahl
- Michael Ficarra
- Nick Fitzgerald
- Dan Phillips
- Yuri Iozzelli
- Paolo Severini
- Frank Emrich
- Sean Isom
- Ilya Rezvov
- Luke Wagner
- Adam Klein
- Jeff Charles
- Zalim Bashorov
- Sam Lindley
- Chris Woods
- Andrew Brown
- Julien Pages
- Robin Freyler
- Ty Overby
- Ricky Vetter
- Alon Zakai
- Deepti Gandluri
- Jakob Kummerow
- Dan Gohman
- Mattias Liedtke
- Alex Crichton
- Chris Fallin
- Daniel Lehmann
- Johnnie Birch
- Bailey Hayes
Proposals and discussions
JS String Builtins: vote for Phase 4 (Ryan Hunt & Adam Klein, 15 minutes)
RH Presenting slides(TODO: link)
JK (chat): can confirm that V8 implements this.
CW: How does the future planned UTF8 support interact with globals where a string is encoded in the name of the global?
RH: If you're adapting the text encoder and decoder APIs, those just provide conversion from arrays or memory holding UTF-8. There's no direct access to UTF-8 code points or anything like that.
CW: So in particular it’s not changing Wasm’s view of the externref string as being of a UTF8 string instead. Makes sense.
PD: there is a “js” prefix in the import statement. How does that work out with other wasm embedders? Does this apply to other embedders that might have similar imports, or general builtin imports.
RH: Good question. The "wasm:" is saying the Wasm spec is defining this. The "js-" says that the interface is to JavaScript strings as provided by the JS spec. All JS embedders should implement this. Other embedders could implement or polyfill this if they want. It’s only really required for embedders that use the JS API. others could but wouldn’t really expect them to.
NF (chat): the proposal is designed specifically for integrating with the host's JS strings, if you don't have a host with JS strings, then it doesn't really make sense
CW: I’d be more positive, I'd be interested in seeing other embedders take inspiration from this to provide string types to wasm.
RH: Yeah, this came up before with the stringref proposal. It’s possible we will see convergence across the ecosystem, in which case implementing a string interface in core wasm could make sense. Starting with just JS / the Web de-risks it.
RV: How long would you expect to take to get the UTF8 extension proposal through?
RH: I think JS strings was about a year from first proposal, but there were a lot more unknowns about the mechanisms for how you define and specify import sets. I expect that if they are well motivated and engines care about them that we could get the time down, but unknown unknowns happen. I would like to propose a follow-on proposal fairly quickly after this, but it might be a month or two.
RV: Is there someone that is kind of taking ownership of that? Or is the UTF8 extension more up in the air until someone decides to pick it up?
RH: I can soft own it. If anyone else wants to pick it up, that would be useful. I'm not deferring to abandon it. There are just some other APIs and memory integration that would be good to do, too.
RV: Would type imports/linear memory stuff be tied to UTF8?
RH: Not necessarily, sometimes it's easier to tie things together and sometimes not. Haven’t thought about it too much.
AK: aside from having 2 VMs and a toolchain, it is being used by Google Sheets, an app using the toolchain, so we have validation of this all the way end-to-end. One more reason we’re interested in standardizing, because we have users that want it in production. I know at least the Kotlin toolchain has been interested in this. As soon as it's standardized they will look into adopting it.
RH: We also did test the Sheets example in Firefox and it worked the first time, which doesn't always happen.
| Vote | Count |
|---|---|
| SF | 22 |
| F | 11 |
| N | 1 |
| A | 0 |
| SA | 0 |
Unified approach to stack switching (Sam Lindley & Francis McCabe, 45 minutes)
FM presenting slides (TODO: slides link)
CW: I'm very excited to continue thinking through how this will compose with the new threads proposal.
SL: I’d also like to thank Conrad for helping make this happen, speaking to several people and helping get people on board
FM: I second that.
CW: team effort!
TL: I’m also very happy with the design we ended up with. Wrt composing with the threads proposal, I know our users are also very interested in this.
FM: work stealing is a major win from that combination
CW: Looking forward to trying this out on the embedded side. We have all kinds of scenarios when we need to pause a thread and give it more information. We contribute to the WAMR side, so keep us in the loop.
FM: Will do. We are very interested in feedback. Also, going forward, we’ll be working by burning down issues. So if you have a question or issue you’d like us to consider, please create an issue in the repo.
SL: Daniel has just about finished implementing the full thing in the reference interpreter, so that could be helpful if you want to try this out, write some code and see if it looks like something you could generate from a compiler.
TL: What's the state of the spec tests, do you know?
DH: They are nonexistent so far. I’m working on that.
ZB (chat): Is this reference interpreter rebased on the main repo?
SL + DH (chat): Yes.
| Vote | Count |
|---|---|
| SF | 21 |
| F | 13 |
| N | 2 |
| A | 0 |
| SA | 0 |
DH (chat): Just to follow up on the reference interpreter question. It is based on the combination of spec/main, function-references/main, gc/main, and exception-handling/main.
CW (chat): It may be worth looking at Andreas' wasm 3.0 fork of the spec as a base? not 100% sure this is the right approach- check with him.
DH (chat): Yes, the latest version is rebased on Andreas' wasm-3.0
FM: the repo is nontrivial to navigate right now, we will clean up the various branches that went into the new design shortly.
SL: the explainer gives a guide that will be helpful.