Using builtins for prototype and descriptor creation

[eqrion]

Here's a sketch of an idea that avoids JS glue code and custom sections. It keeps custom descriptor types, but uses imported builtins for creating prototypes and associating them with descriptors.

I probably missed a couple use cases or requirements, so let me know if this seems feasible or not.

Calling imports from globals

The first thing we'd need is a core wasm extension to allow globals to call imported functions in initializer expressions. By itself this is dangerous due to the possiblity of re-entrance to a partially constructed instance from the called imported function. For example:

(module
    (* (x) => x() *)
    (import "" "invoke" (func $invoke (param funcref) (result i32)))

    (global i32 (call $invoke (ref.func $invokeMe)))
    (global $nonNullableGlobal (ref struct) ...)

    (func $invokeMe (result i32)
        ;; called by the $invoke function through funcref during global initialization
        ;; can do bad things like access nonNullableGlobal before it is initialized
        ...
    )
)

The issue is that globals are defined after the function section, and can therefore acquire references to defined functions (which close over the partially constructed instance) and pass those out to the wider world.

One workaround to this is to relax the order of the global section and allow repetition of it. Then we could say calling an imported function is allowed if the global is defined before the function section (the 'early' globals). Globals defined after the function section (the 'late' globals) would not be able to call imports, but could acquire funcrefs defined in the module.

Builtins for creating prototypes

If we can call imports during global initialization, then we could define builtins for creating prototypes.

One idea is to define a builtin which allocates a wasm struct and gives it field names that JS can access.

"wasm:js" "struct.new_with_names"
  (param $structFieldValues) (param externref $structFieldNames) -> (ref $struct)
  where $struct is a struct type with $structFieldValues. len($structFieldValues) == $structFieldNames

The resulting struct object is a normal wasm struct, but JS can get/set the fields through the names that was provided on creating. You could think of this as sugar for the simple case of Wasm-JS interop where you just want the struct fields to show up as own properties.

With this builtin, modules could construct all of their prototype objects using wasm structs in globals. The prototype struct fields that are methods would need to be initialized later, because the prototype globals are 'early'. I think if you have mutable nullable fields for each method, the prototype structs could be initialized in the start function.

This imported builtin is polymorphic depending on the type signature you import it with. The func type you use in the import contains the struct type, which is used to generate the correct logic for the builtin. Polyfilling this builtin is probably possible, but a bit convoluted. A name mangling approach would be easier to polyfill, but I think name mangling should be avoided.

We could also have a struct.new_with_names_and_proto builtin for if a prototype is in a chain.

Builtin for creating custom descriptor with prototype

Similar to above, we could then create a builtin for allocating a descriptor struct with an associated prototype.

"wasm:js" "struct.new_desc_with_proto"
  (param $structFieldValues) (param externref $proto) -> (ref $struct)
  where $struct is a struct type with $structFieldValues.

This could be used in the early global section to create the descriptors. If the descriptors have funcrefs from the module on them, this would require those to be mutable and initialized during the start function (this might be an issue for vtables, or are those stored in a struct pointed to by the descriptor?).

Function receivers

One other thing the custom section approach does is create wasm funcs that take the JS receiver as the first parameter. An alternative using builtins would be:

"wasm:js-function" "to-method"
  (param funcref) (result funcref)

It would construct a new wasm function that wraps the inner wasm function. When called from JS it has the alternative behavior of requiring a receiver and passing it as the first wasm param.

#31 proposes another alternative which doesn't allocate a wrapper wasm function, but mutates the behavior of the existing one. That could also work here as a builtin.

[tlively]

My initial reaction is that this seems feasible, but is more invasive in core Wasm than the modular custom section approach. Can you say more about what value you see with this approach relative to the custom section approach?

I also want to note that what we've heard from toolchains so far is that exposing methods via prototypes is much more useful than exposing named fields directly, so that's what we've been optimizing the design for so far.

[eqrion]

My initial reaction is that this seems feasible, but is more invasive in core Wasm than the modular custom section approach. Can you say more about what value you see with this approach relative to the custom section approach?

Good question, I guess I skipped over that part.

The advantage of declarative formats is that they can be heavily optimized for their specific use cases. But they are more brittle for if something falls off the happy path. We already have globals and initializers that are both powerful and also well optimized by engines. It seems like if we're able to add a couple extensions (I don't think the ones proposed are that large) to make globals even more powerful, that will be more future proof as more requirements come up down the road.

It's also moderately nice to avoid introducing a new custom section that is critical to validation unless we really need.

I also want to note that what we've heard from toolchains so far is that exposing methods via prototypes is much more useful than exposing named fields directly, so that's what we've been optimizing the design for so far.

No doubt. Having a builtin for creating a wasm struct with JS named fields is really just for simple cases, like potentially prototype objects, where the overhead of creating a prototype, getter methods, and custom descriptor just to have simple field access is overkill. But I think it only really makes sense as a sugar over those things.

[sjrd]

That looks promising, though the following might be a blocker:

This could be used in the early global section to create the descriptors. If the descriptors have funcrefs from the module on them, this would require those to be mutable and initialized during the start function (this might be an issue for vtables, or are those stored in a struct pointed to by the descriptor?).

That is definitely going to be an issue for vtables. Whether they're in the descriptor struct (for actual vtables) or pointed to from the descriptor (for interface method tables), you want them to be non-nullable, and therefore initialized at creation. That's important not to have null checks on the vtable dereferences.

Moreover, you also want them to be immutable. If they're immutable, a Wasm-to-Wasm optimizer can do CSE and LICM on their accesses. We have benchmarks where the dominant profiles come from repeated pointer chasing of the same interface method tables in a loop. I haven't had time to contribute CSE and LICM yet to wasm-opt, but I intend to do so (for the non-flat structure). To be able to do it at the Wasm level, without assuming toolchain semantics, you need those pointers to be immutable.

[tlively]

My initial reaction is that this seems feasible, but is more invasive in core Wasm than the modular custom section approach. Can you say more about what value you see with this approach relative to the custom section approach?

Good question, I guess I skipped over that part.

The advantage of declarative formats is that they can be heavily optimized for their specific use cases. But they are more brittle for if something falls off the happy path. We already have globals and initializers that are both powerful and also well optimized by engines. It seems like if we're able to add a couple extensions (I don't think the ones proposed are that large) to make globals even more powerful, that will be more future proof as more requirements come up down the road.

It's also moderately nice to avoid introducing a new custom section that is critical to validation unless we really need.

Agree that the custom section approach is great for targeted use cases and doesn't help if you're off the happy path. I think that in the case of the proposed modular custom section design, though, that risk is mitigated by building the custom section semantics on top of JS APIs that are also exposed for direct use and by allowing the user to pre- or post-configure the prototypes used or created by the custom section however they want.

[eqrion]

@sjrd

That is definitely going to be an issue for vtables. Whether they're in the descriptor struct (for actual vtables) or pointed to from the descriptor (for interface method tables), you want them to be non-nullable, and therefore initialized at creation. That's important not to have null checks on the vtable dereferences.

Ah okay. In that case, using a builtin function to construct the descriptor structs won't work and we'd need to have it be an instruction. The other builtins would still be useful here. My preference for creating the actual descriptor struct would then be something like #2 (comment), which would let descriptors be created in globals without any JS glue code.

@tlively

Agree that the custom section approach is great for targeted use cases and doesn't help if you're off the happy path. I think that in the case of the proposed modular custom section design, though, that risk is mitigated by building the custom section semantics on top of JS APIs that are also exposed for direct use and by allowing the user to pre- or post-configure the prototypes used or created by the custom section however they want.

I think the risk here is that there's a large performance and toolchain complexity cliff between the modular custom section, and using the imperative API. So when someone runs into something the custom section can't do, it turns into pressure to keep extending the custom section for "just one more feature". Which leads to it eventually turning into a small general purpose programming language for constructing JS objects (when we already have one).

For example, I could imagine that some users would want some prototypes or fields to be conditionally created depending on runtime feature tests. Either we don't support that in the custom section, and then those toolchains need to maintain two different paths with potentially much different performance. Or we do support that, and the custom section is much more complex.

So I guess I'm trying to come at it from the other direction and think what are the minimal extensions to our preexisting general purpose language (core wasm) which could make it do the initialization fast enough. Globals and the start function are already very powerful, and it seems like if we could just make them slightly more powerful that might be enough.

[lukewagner]

That is definitely going to be an issue for vtables. [...]

My preference for creating the actual descriptor struct would then be something like #2 (comment), which would let descriptors be created in globals without any JS glue code.

#39 provides some additional options for rationalizing how to pass in the extra externref to struct.new. One way or another, it seems like we should be able to pass an externref describing a JS prototype to struct.new.

So just to check if we're on the same page of how this could work at a high level:

1. JS-builtins are imported for creating or acquiring JS prototype objects. Using an "early global", these JS built-ins are called from an initializer expression to store all the required prototypes in global externrefs.
2. Descriptor objects are created via struct.new* and stored in an (immutable non-null) global (ref $some-struct), passing in the prototypes from Step 1 via global.get arguments.
3. JS-builtins are imported for adding properties/methods/etc. These are called in the start section, using ref.func to acquire funcrefs as needed (avoiding the need to export/name each one).

Does that sound right?

As @eqrion noted, this approach has some nice incremental polyfillability characteristics which I expect will be important as new use cases are found over time that motivate new built-ins in steps 1 and 3.

Another nice benefit is that, because Step 3 can run at the very beginning of the start function (emitted by the toolchain) before any user-defined (top-level script or global object constructor) code, the prototypes can be setup before the first import call so that any wasm-GC objects passed to JS work as normal. IIUC, the custom-section-based approach will not be semantically allowed to setup the prototype until after the start function returns.

[tlively]

Is there an advantage to using "early globals" and imported builtin functions to produce JS prototypes in step 1 over simply importing the prototypes (or their wrappers) directly? The latter would not require any new notion of early globals or constant import calls, so it seems significantly simpler to me.

[lukewagner]

Totally. I had thought that perhaps there was a goal to do this more "declaratively" inside the wasm engine as a way to avoid JS glue / size overhead, but if not, then yeah importing JS prototypes via externref seems great.