- Where: zoom.us
- When: April 11th, 4pm-5pm UTC (April 11th, 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)
-
Proposals and discussions
- Add a
_initializeconvention in tool-conventions
- This would add a new tool-conventions document named
BasicModuleABI.md which would define the
_initializeconvention. - See WebAssembly/tool-conventions#203 for details.
- Add a
-
Closure
None
None
- Sergey Rubanov
- Zalim Bashorov
- Dan Gohman
- Paolo Severini
- Jeff Charles
- Yury Delendik
- Alex Crichton
- Ryan Hunt
- Andrew Brown
- Ben Titzer
- Chris Woods
- Yuri Iozzelli
- Brendan Dahl
- Alon Zakai
- Ashley Nelson
- Emanuel Ziegler
- Manos Koukoutos
- Thomas Lively
- Dan Phillips
- Nick Fitzgerald
- Petr Penzin
- Deepti Gandluri
DG (Dan): we want to implement C++ constructors and similar. If we have a main function, we can just put the call before the user code starts. But if there’s no single entry point, there's a question of how to run them at the right time. So we are proposing a tool convention, but this is somewhat unconventional because it spans more than just one toolchain.
We’d have the _initialize function which would be exported, and the users of the module would have to recognize.
With the component model we are also discussing adding a second init phase, after the imports are initialized. This would be a good match, the component model exports a more limited interface.
For core Wasm this is more complicated to do due to interactions with JS, we sort of need to have an in between phase so that the component model doesn’t have to deal with the things that have to run before the start function We’ve looked at a few alternatives… could we use the wasm start section, but that doesn’t work because the imports aren’t available yet. And we need to be able to do arbitrary things like read()/write() in constructors.
Also tempting to define a second initialization phase in core-wasm. core -wasm members expect to have mopre control of exports, so that would be hard to do.
Another option could be to have wasm-ld automatically wrap the exports. The wrapper would have a check that runs the initializer if it’s not been done yet. There are concerts about overhead, people don’t want to deal with the overhead of an extra branch at every initialize.
And lastly, the name. Call it _initialize, or _wasm_call_ctors, or what. We use_initialize in WASI, it seems fine, but open to input there too.
Do people have thoughts about this? Questions? Suggestions?
PP: is there currently work to use this in something non-component-model based?
DG: This is entirely not about the component mode, this more about how do we implement C++ constructors for core wasm?
PP: is there an effort to implement this in the toolchain?
DG: Variety of efforts, wasm-ld grabs every export, there’s code in wasi-libc, one of the issues there right now is that we want C++ constructors
There is also code in wasi-libc to do _initialize as described. But we want C++ constructors to work even without WASI since C++ should work across all wasm environments, not just WASI.
DG: We have implementations, biut looking for a standard convention, we should have a unified answer to this
DS: Bit of context to add, today we have the tool conventions repository which has been primarily for documenting how the LLVM based tools do things so that other things can use LLVM in the same way or interoperate with them and it’s sort of describing how one ecosystem works. But the reason this is interesting is the hope it would be a little broader than one toolchain or one set of toolchains on one set of infrastructure. So the scope is a little bit broader.
DG2 (Deepti): Have y’all talked about separate place for something that’s broader? I know sometimes tool conventions has been a catch all for a bunch of different things, so I don’t want to open a discussion about what the toolchain repository should be or if there should be a new repository. But I wanted to know if these discussions have already taken place.
DG: If we don’t put it in tool conventions, the other place that makes sense is core-wasm spec but that opens up a can of worms, is this the initialization phase and how do we define that? It makes things more more complex. Push the problem onto the host environments that doesn’t allow us to say much about those environments but ensures that initialize is called before anything else. A whole new document just for this feels awkward. What else would we put in this document? It would be this one thing, and would we make a standard for the other initialize functions? Seems silly but we could do that. Part of the guidance I’m looking for is what should we do here? A whole new standard for this seems unjustified but maybe we should. I don’t know.
BT: about exports: one of the important ones is memory, used by lots of APIs. are there other exports that are relevant here?
DG: The function table, if you want function pointers across boundaries, you would need the function table. Other than that, exporting malloc is also pretty common, to call back in and allocate memory inside the module.
AZ : It might be helpful to clarify which VMs and toolchains would be expected to call _initialize. (web VMs, server VMs, others, etc.?)
DG: Don’t know the answer to this, if you’re using wasm32-unknown-unknown, they shouldn’t expect to know about this, and the user code would have to deal with it, but VMs could automatically do this
NF : on the web would it be automatically called, or would it be the JS?
DG: on the web, I don't think we’re proposing changing how browsers work. That seems like a pretty significant step. We could?
TL: Difficult to figure out how.
DG: That’s also a basically a second initialization, so it’s basically the same problem. The places we can call automatically mostly are the places that don’t have JS. in a non-JS engine, the host doesn’t really have any purpose for the exports, so it can just call _initialize automatically. But on the web where there are users of the exports, it’s important.
DG: We’re not going to define the function, but its up to the user to define it, it can have undefined module if not defined right; So I’d expect that we wouldn’t put it in the browsers, we’d tell toolchain developers or users that they’d need to call _initialize if it exists.
PP: if the problem is that there are things that are not initialized, so you need a second function. Can you have a convention that this is still part of init but called after everything is set up? Maybe this is a naive question…
DG: The challenge with the second initialization function is defining when it runs. We want the function to get called after the exports are available, JS code expects autograbbing of exports, in JS we have async await, but we don’t have that in Wasm, if we build a second initialize then we have to call into JS before the exports are available, and call back into Wasm and then back out into Wasm again to be able to suspend the way JSPI expects
One option we discussed was a callback. In a way _initialize is like that but only host code knows when it has to run.
PP: Makes sense. Some kind of callbacks for system functionality could be useful. E.g. in wasi-threads, libc provides the support vs libc in emscripten which does a lot more, but there is missing a place to put that
DG: Primarily looks like a direction, if there should be a callback scheme, then we could go that way
BT: I don’t have an answer but It looks like there’s almost a recursive dependency between imports and things that you export. You kind of paper over this but if there was a more explicit way to express dependencies between imports and exports, eg. repeated section. Component model does this with multiple modules. But we don’t have a way to express in core wasm.
DG: A phased instantiation type of scheme?
BT: A little like that, you can import things that don’t depend on something, that can be used directly, if you have an export that depends on an import, then you want to be able to export before the imports are defined. Luke, any thoughts? I fundamentally see it as an ordering dependency issue.
LW: I think it raises some of the cyclic dependency questions that get difficult quickly. DAGs are straightforward but it gets complicated quickly if you have cycles.
DG2: Any objection to this going into the tool conventions repository to start with? What is the best next step forward?
LW: were you suggesting this in tool conventions?
DG: yes, this link is a PR there. Would be a new file called BasicModuleABI.md
DS: You’ll probably spend more time describing what this document is, and what it should do than the technical part :)., if we don’t have a clear path forward for now, then it makes sense to put it in tool-conventions now and we’ll have something to refer to in the future if we want to do multi phase instantiation, or better dependency management, this could be relevant to that and at which point we’ll have a better idea what to do with that.
DG:
DG2; Any objections to starting in the tool conventions repository as DG proposed?
No objections raised.