High-level Q: JS interop vs. core Wasm

[jakobkummerow]

I think some of the opinions that folks have on their preferred design approaches are consequences of more general thoughts about how features and specifications should be organized, so I figured it might be productive to take a step back and talk about those.

In short:

Do we prefer it when JS-relevant things are kept out of core Wasm (and instead are e.g. confined to a custom section that non-JS embedders can ignore), or do we prefer to have them in core Wasm (so that custom sections don't become too load-bearing or too powerful)?

As a third option, is it perhaps time to resolve this by introducing a third kind of section, let's call them "embedder sections" for now, that are validated like regular sections, but specified in embedder/API specs rather than the core Wasm specification, and meant to be ignored by other embedders to whom they are not relevant?

Or is this not the dichotomy you see; would you characterize in different terms what you find most important/desirable about the way embedder-specific behavior is specified and integrated with core Wasm?

A concrete example from this proposal, illustrating what these principles could mean in practice:

Any declarative way to set up JS prototypes with methods fundamentally needs to express tuples
(which function, as which method name, on which prototype, and is it a method|getter|setter).
There are several ways how this can be accomplished:
A. We could define a new kind of export section entry for this. That would maintain the principle that there is only one export section that lists everything that the module exposes to the outside world. On the other hand, this export section would then contain a lot of JS-specific things that are most likely useless to non-JS embeddings.
B. We could specify a second kind of export section; that would either be a "Custom Section" as they stand today, or the new "embedder section" kind mentioned above. That would mean that the set of publicly exposed things is now defined by the union of two sections. It would also mean that for any tool/engine that doesn't care about JavaScript, it's very easy to ignore the things that are only relevant for exposure to JavaScript -- which reflects the reality that for, say, an AOT optimizer targeting maximally-efficient modules for non-Web embeddings, it would be desirable to only consider those exports as publicly exposed that are actually relevant in that context.
C. We could aim for a kind of middle ground: existing (or perhaps new) kinds of export section entries must ("passively") list everything that's exposed publicly, while a Custom Section contains the actual declarative instructions what to do with them (the 4-tuple sketched above). That would maintain the principle that the export section lists the module's entire public interface, and it would avoid adding JS-related spec text to core Wasm. But in actual modules the JS-related stuff would pollute the "core" part of the module: there would be a bunch of exports that are useless outside a JS embedding, yet are (probably?) impossible to ignore or strip out by engines or optimizers, because there's no way to identify them as ignorable.

I think that each of these approaches has pros and cons, and I expect that each will have its supporters. I assume that these individual opinions are to a large extent based on prior, more general idealizations of how embedder-specific behaviors should be specified. So before debating and tweaking the specific details, I think we might want to find consensus on the general approach first.

Further, I think this is largely a question of personal preference, so one way to resolve it is by majority vote, and a "temperature of the room" reading in that sense would be a fine outcome of this thread. That said, if you can articulate specific reasons why your preference goes one way or the other, that would be particularly valuable for finding consensus: you might convince someone else of your reasoning!

[jakobkummerow]

To put my own cards on the table:

Since I work on a Web embedding, I don't get to enjoy the luxury of ignoring JS-specific things, so I don't have strong reasons to care how formally separated they are. I'm sympathetic to the idea of keeping them separate though. What I do strongly care about is efficiency and performance; and often making things fast and lean requires putting them "close to the core" (as opposed to forcing them onto the detours of indirect approaches). That's easily accomplished when everything is in core Wasm; in order to maintain some separation I find the idea of embedder-specific sections rather appealing. But they don't need to exist as an explicit concept if we're okay with giving custom sections enough power and expressiveness (within reason, of course; certainly wouldn't want to paint ourselves into a corner that will be annoying in the future).

In terms of the concrete examples, I would be equally happy with A or B, mostly because to a Web embedding the difference between them is very minor. I imagine that non-Web Wasm engines would likely prefer B. I'm skeptical about C, because (for both Web and non-Web embeddings) it's less efficient than either A or B would be, and I struggle to see any advantages it would have over A or B that would outweigh this drawback.

[tlively]

I think it's extremely important that the core Wasm spec not include anything specific to JS or any other embedder. The core spec should remain self-contained and embedder-agnostic to ensure that Wasm remains a portable and universally useful tool for expressing pure computation.

I also think it's important that Wasm present a simple, modular embedder interface with clear abstraction boundaries. To be more specific, it is valuable to maintain the property that only explicitly imported or exported module fields and values obtainable via those exports are in any way visible to the embedder. This clear boundary lets WebAssembly producers, optimizers, and engines reason about how they can change their compilation schemes or how they can transform code without fear of introducing inadvertently observable changes. If we relax this abstraction boundary and let embedders observe the internal structure of WebAssembly modules, optimizations that were previously valid might become invalid. There is always a risk that existing optimizations are broken when they rely on undocumented and unintended invariants of WebAssembly's design that are broken by new features, but in the case of the embedder API, the invariants are both intentional and well-documented, so we should preserve them.

In general I think it's reasonable for specifications for things that are too high-level or embedder-specific for core Wasm to be layered on top of the core Wasm spec, but these layered specifications also need to respect the core Wasm abstraction boundaries. If these specs could observe a core module's internal structure, it would cause all the same problems that would be caused by letting embedders observe internal structure. So far the JS and Web embedding specifications respect these abstraction boundaries, and we should maintain that property.

To apply these design principles to the concrete options:

A. We could define a new kind of export section entry for this. That would maintain the principle that there is only one export section that lists everything that the module exposes to the outside world. On the other hand, this export section would then contain a lot of JS-specific things that are most likely useless to non-JS embeddings.

Adding a new kind of export section entry only makes sense if it can be made sufficiently embedder agnostic. I agree that classifying exports as getters, setters, or regular methods is probably fairly JS-specific, so I think it's a stretch to say that it meets the bar for inclusion in core Wasm.

B. We could specify a second kind of export section; that would either be a "Custom Section" as they stand today, or the new "embedder section" kind mentioned above...

A custom section should not affect a module's external interface, so it should not be able to add new exports. An embedder-specific section could be separately specified as a layer on top of core Wasm, but it also shouldn't be able to reach inside the core Wasm module and add more exports.

C. We could aim for a kind of middle ground: existing (or perhaps new) kinds of export section entries must ("passively") list everything that's exposed publicly, while a Custom Section contains the actual declarative instructions what to do with them (the 4-tuple sketched above). That would maintain the principle that the export section lists the module's entire public interface, and it would avoid adding JS-related spec text to core Wasm.

This is the only path that is consistent with the design principles I believe we should maintain.

But in actual modules the JS-related stuff would pollute the "core" part of the module: there would be a bunch of exports that are useless outside a JS embedding, yet are (probably?) impossible to ignore or strip out by engines or optimizers, because there's no way to identify them as ignorable.

For producers that want to produce portable modules, I don't see this as being materially different from the existing burden of having to stub out or polyfill other platform-specific imports. Producers are also free to specialize their modules for different deployment targets if they prefer, so no one is forced into this cost. I view this downside as being very small compared to the upside of maintaining core Wasm's current abstraction boundaries.

@eqrion, @kmiller68, @rossberg, @conrad-watt, @lukewagner, @titzer and everyone else in the community, it would be very helpful to record your thoughts on this.

[rossberg]

@tlively, I agree with everything you said.

[jakobkummerow]

@tlively:

clear abstraction boundaries

Sure, that's a great principle and I don't think anyone disagrees with it, but I don't really see how it applies to the question I raised in this thread. Let me try to rephrase:

"We need to export some things for the primary benefit of JS-side prototypes. Should these go into:
(1) existing kinds of export section entries?
(2) one or more new kinds of entries in the existing export section?
(3) a new kind of export section?"

All three of them maintain "clear abstraction boundaries", none of them "rely on undocumented and unintended invariants", and of course in all three cases the module has full control over what is or isn't exposed to the embedder. The differences between these options mostly concern logistics and aesthetics, AFAICS.

the upside of maintaining core Wasm's current abstraction boundaries

None of the proposed solutions entirely maintain the current abstraction boundaries, so this ideal as stated also isn't immediately applicable to this thread. The question is which capabilities we want to add to the embedder interface, not whether we want to make changes. It is reasonable (though at least somewhat subjective) to argue that some of the options are less intrusive than others, or more in line with past decisions; but claiming that one design could work without any changes to the existing abstraction boundaries would be factually incorrect.

---

Far less important side note:

classifying exports as getters, setters, or regular methods is probably fairly JS-specific

FWIW, that is, at least to some extent, debatable. Many languages have the concept of accessors; for example C# has direct syntax support for them, Python has decorators for them. There just don't happen to be popular Wasm embeddings in these languages (yet?). So for the time being, we are clearly focused on the JS embedding, and can decide to say that whatever we design for it is JS specific. However, we could also emphasize that if/when folks start loading Wasm modules directly from their Python programs, they should be able to reuse these things; so that could be (part of the) justification for specifying things in core Wasm if that's where we want to specify them.

[tlively]

None of the proposed solutions entirely maintain the current abstraction boundaries...

Can you explain how the design currently described in the explainer, which is a variant of option (C) and uses the existing import and export sections unmodified, violates the current abstraction boundaries?

[jakobkummerow]

It needs to retrieve and inspect the type of an object, that type's descriptor, and the type of the descriptor's first field. And then it also needs to fetch the object's actual descriptor value and the value in that descriptor's first field. See steps 4 through 10 of [[GetPrototypeOf]].

Nothing in the module indicates that the precise type of the first field of descriptors or the values stored in those fields are externally visible (in fact, before this proposal, all struct fields were generally invisible to embedders); and yet the "Modular" design crucially relies on no optimizer messing with that field in any way (such as dropping it because it's unused, or reordering it, or modifying its type). "optimizations that were previously valid might become invalid" is a fair concern, but from the perspective of this concern, it's not clear to me that either of the possible designs has a distinct advantage over the other.

[tlively]

Inspecting the type of a reference value is already possible via the ref_type(store, ref) embedder interface function. And because the types are closed and do not contain module-specific type indices, and also because types are structural, this is already enough information for the embedder to synthesize a type section defining that type. From there the embedder can synthesize an instance that can retrieve arbitrary fields or descriptors from the value. So inspecting types and values does not require any new capabilities in the embedder interface. (And note that these existing capabilities would be exposed to the JS embedding in particular by JS type reflection, which has not been controversial.)

Existing optimizers already cannot change the types or contents of values that might flow out of the module because such changes would be observable by other instances those values might flow to. Binaryen only performs optimizations that might make such changes when the user passes the --closed-world flag, promising that the environment will not inspect any values.

[eqrion]

@jakobkummerow I'm generally in agreement with @tlively's first post here.

As a third option, is it perhaps time to resolve this by introducing a third kind of section, let's call them "embedder sections" for now, that are validated like regular sections, but specified in embedder/API specs rather than the core Wasm specification, and meant to be ignored by other embedders to whom they are not relevant?

I think if these section must be strictly validated, yet are defined in specs outside of the core wasm spec, we're in a similar position as the component-model. So we'd want to define a new layer larger than a module with corresponding file format which embeds the core wasm format within it. e.g. a .wasmjs module. The JS-API spec would probably be the place to define this all out.

This would all be possible, but would be a lot of work and ecosystem fragmentation and so I think we need to exhaust all our other options first.

@tlively

I think it's extremely important that the core Wasm spec not include anything specific to JS or any other embedder. The core spec should remain self-contained and embedder-agnostic to ensure that Wasm remains a portable and universally useful tool for expressing pure computation.

I basically agree with this, but I think one nuance is that the core spec should make reasonable affordances to aid embedders. externref is a good example here. It's intentionally embedder defined and not pure compute. But it makes integration between core wasm and host code much simpler if core wasm can directly hold onto host values. It's also low impact on the core spec, as it doesn't need to enumerate all the different kinds of host values, just a single opaque value.

For example, in #2 (comment) I proposed that the instruction for constructing a descriptor struct could have a host extension point by taking an optional extra externref value. Small affordances like that which could be usable by multiple hosts, but yet minimally impactful on the core spec are nice. I'm not stuck on that particular idea, just the principle that something like that is acceptable to me.

[lukewagner]

Agreed with @tlively's comments with the nuance @eqrion mentioned. In particular, I think we should make every effort to address these JS use cases in terms of embedder-agnostic core wasm + JS API additions before we resort to the custom/embedder section escape hatch as this will improve core wasm for other non-JS use cases.