- Where: zoom.us
- When: June 9th, 4pm-5pm UTC (June 9th, 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.
- Update on Module Types / Module Linking proposal (slides)
- Poll: Rename "Module Types" to "Module Linking", broadening scope as proposed in PR #3 and advance proposal to stage 1
- Discuss numerical values in data segments proposal. (discussion link and semi-formal description repo)
- Discuss removing type annotation on ref.is_null (issue)
- Closure
None
None
Wouter van Oortmersson
Jacob Mischka
Ezzat Chamudi
Zhi An Ng
Francis McCabe
Luke Imhoff
Lars Hansen
Rick
Deepti Gandluri
Ben Smith
Thomas Lively
Paolo Severini
Jay Phelps
Zalim
Arun Purushan
Nabeel Alshamma
Conrad Watt
Alon Zakai
Pat Hickey
Ryan Hunt
Pat Hickey
Alon Zakai
Ross Tate
Heejin Ahn
Flaki
Jakob Kummerow
Michał Kawalec
Clemens Backes
Luke Wagner
Derek Schuff
Alex Crichton
Sven Sauleau
Till Schneidereit
Adam Klein
Emanuel Ziegler
Richard Winterton
Manos Koukoutos
Andreas Rossberg
Sam Clegg
Gergely Buday
Dan Gohman
Petr Penzin
JensenGrey
Mingqiu Sun
Luke Imhoff seconds
Update on Module Types / Module Linking proposal (slides)
[Luke Wagner presenting]
AR: That might not work for type imports
LW: You're right about that, but for existing things like Functions it could work. That's why I put a "perhaps"...
RW: You said that a child module could inherit permissions from parent module. How is that protected? Can I write a rogue module and inherit it?
LW: Inherit might not be the right word, it’s explicitly passing capabilities - the child can ask for anything, but the parent has to choose to give it to the child module - more like function arguments
RW: I would ask for it as a child, and then the parent would ...
LW:
RW: Makes sense.
FM: In JS land, it’s important to be able to know whether you have the original of something...
LW: That was a contentious statement in the get-originals proposal... but then there were security implications there. But then it was decided that you could ask for the originals, but wouldn't necessarily get them. Then the proposal was set aside for the time being.
FM: So this is important in cases where the application is not in complete control of itself - if you go upto a browser extension, that has loaded some code that ahs virtualization capabilities, and injects some nasty stuff - that’s probably the business use case for it
LW: I think in the web discussion; they said that if you run first, then you get control of whatever runs after you. In JS, it's because you can monkey-patch the global. So if you need to be in control, you need to be the root. But if you're a random wasm module that means you can't necessarily be the root. It's at odds with virtualization.
FM: Maybe.. A compromise is to have some signal saying you have been virtualized or something like that
LW: It's worth discussing ...
FM: The thing about running first is problematic because you don’t always know..
LW: It's the web developer who writes the document that can make the choice.
FM: The CDN gets...
LW: It's a good question.
FM: In Java class loaders it's arranged so that you cannot override the definition of your parent class loader... e.g. a definition of String, any class loader that's loaded by defining one for String cannot override String. The reason for this was security -- it makes it awkward to use though.
LW: One thing we have to sidestep is that we don’t have a global mutable state that’s shared by different modules, that’s probably a partial solution at best..
PP: Out of scope perhaps, but potentially you could make a standard library functionality that the library could depend on. You can imagine a situation where a module comes from a library with a different toolchain, you may see mismatches like we see in the native world.
LW: When you can make your own instance, it’s okay to have two modules that import different C-libs.. It gives us new levers, if everyone imports the same libc, then they have to agree on the major version, but otherwise..
PP: Is there a way to check the version?
LW: You can say in the string, you could put the version in the string, and the type captures semantically what you depend on, and those two things are the signal to the outside world.
LI: This was listed as feature work,(Explains with Erland example) but can this exist outside the browser - will this allow for replacing yourself? Kind of doing it yourself..
LW: Not as some intrinsic feature. But if you had a dynamic instantiate API you could implement that transfer of state at a higher level. But not as an intrinsic.
LI: We’re fine without become, we just have to write so much JS glue code, but it would be nice to do it just in Wasm
LW: That may be a more advanced future use case. For now, all the instantiates are declarative. A compiler could look at this and generate everything. It's a later feature to have runtime instantiation. Current proposal doesn't allow this as at all. First class instantiation requires GC, since you can make cycles, and we don't want to require GC for something like dynamic linking.
LI: Going back to prev conversation - an objection to virtualization check is that checking if you’re in virtualization or debugging is how viruses hide from anti-virus software
LW: It would break various abstractions that you would otherwise have.
RW: Yeah, if you can replace yourself, then you could be replaced with a rogue module... I'd be nervous about that.
LW: Not sure what replace would look like…
RT: When you have commands like instantiate - they’re stateless correct? If you run instantiate for example,
LW: The start function gets invoked as part of instantiate...
RT: You may want to think about delayed start so you can run a bunch of these in parallel
LW: The resource allocation... the runtime machinery can be parallelized before start functions fire, but once you do one, you need a specific order. For AOT compilation, where you can parallelize these...
RT: Something to think about.. You could divide it into phases.. Given this can I get exported types, or a pointer to that without instantiate to speed this up
LW: Definitely compilation can happen eagerly... and instantiation is supposed to be cheap in wasm, so in theory we're OK. But yes, we should be mindful of this. That's why it's currently declarative.
POLL: Poll: Rename "Module Types" to "Module Linking", broadening scope as proposed in PR #3 and advance proposal to stage 1
| SF | F | N | A | SA |
|---|---|---|---|---|
| 17 | 14 | 2 | 0 | 0 |
Discuss numerical values in data segments proposal. (discussion link and semi-formal description repo)
[Ezzat presenting slides]
PP: I think it's a good idea, good for developers. Right now, if you want to understand the text format with floating point numbers, it's pretty hard.
CW: Is there any change to the binary format? If you convert back to the text format from binary, will you lose the changes?
EC: There will be no changes in the binary specification - maybe we can still convert back to the normal thing - in the binary ithe type isn’t mentioned they’re flat numbers
JP: It could be in a custom section if you wanted it to.
WVO: Is there any alignment applied?
EC: For now no, it’s another way to specify string
LI: Should it error out if the literal is outside of the range?
EC: In my demo it’s an error for now
LI: Sounds good.
RT (in chat): Consider signed vs. unsigned
BS: wanted to get more people aware. We did not explicitly state there this is a poll, but perhaps implicitly.
DG: we should have the poll on agenda before we poll
TL: adjust rules for phase 1 poll, since the bar is lower
BS: yea, probably discuss next time. Follow our rules right now.
Discuss removing type annotation on ref.is_null (issue)
CW (in chat): I think the type should be [] -> [i32]?
LW (in chat): Also select is only polymorphic over numerics, iirc
LI: Is this considered a breaking change?
AR: Not a breaking change, the proposal isn’t a standard - it’s new in this proposal that changes the binary format
LI: If you are using the feature in browsers that have implemented this already, then it will be breaking.
AR: Yes, you have to assume there can be breaking changes before phase 4.
TL: Can we do a straw poll to gauge interest?
AR: Implicitly this is saying that we are betting on the future that we won't need type annotations for this sort of instruction.
FM: How certain are you that we don’t need type annotations for those instructions?
AR: As a general rule we will not require it on every instruction. There still are instructions where this will be required. For example, select has a principle type, so it needs a type annotation.
LW: We made the existing select change, this is just following through with that.
AR: Yes, in a way this isn't something new.
[no objections to straw poll]
AR: Let's move forward assuming that the poll will go through; so implementers can make progress over the next two weeks, then ask for formal poll and phase 4 poll at the same time.
[no objections]
FM: Process question - what is the criteria for needing a formal poll? Does a change to a proposal need a Poll? Or is it just for proposals?
At time, moving the discussion to github/next meeting.