How to specify function wrapper APIs?

[tlively]

As we've discussed at various points, we still need to spec two APIs for wrapping WebAssembly functions: one for allowing the functions to be called with new and another to pass the receiver as the first parameter. These functions should be similar to these wrappers you can write today:

function callableWithNew(f) {
  return function(...args) {
    return f(...args);
  )
)

function withReceiver(f) {
  return function(...args) {
    return f(this, ...args);
  )
)

However, we would prefer not to have to materialize these wrappers in stack traces or fake making their bodies available via toString(), etc., which suggests these should not be normal JS functions. But we also don't want them to be WebAssembly.Function instances with the associated Wasm types and linking semantics because that would inhibit the optimizations Binaryen can do to the types of functions that can be passed to configureAll.

How can these best be specified?

cc @rmahdav @jakobkummerow

[guybedford]

Could these be implemented via something like a bulk version of a JS fn.bind() builtin applied (albeit with entirely different semantics of course), where you obtain new funcrefs with these new properties from the original funcrefs, and with the wrapping elided?

[tlively]

I think doing this as a normal JS API in the WebAssembly namespace would be simpler than doing this with another Wasm builtin. There's no need to do this wrapping in WebAssembly itself.

[jakobkummerow]

I think toString() is not a problem because it can return { [native code] }. For comparison, see e.g. WebAssembly.Module.toString().

I think stack traces aren't specified anyway, so it's probably not a spec violation not to show these wrappers. They're also not useful to see for debugging, since you can't set a breakpoint in them anyway. (Additional background on why stack traces are an issue: in optimized code, we want to optimize these wrappers out, so they wouldn't physically be on the stack, and we'd have to fake those stack trace entries if we insisted on showing them, which is a bit tricky. In unoptimized code, the wrappers do exist as call frames on the stack, but they're easy to hide for consistency.)

So overall, I think it's probably fine to simply state that the wrappers behave as if created by the JS snippets in this thread's OP. Or you could express what those snippets do in spec language (and perhaps include the snippet as an illustrative note in the spec).

[eqrion]

But we also don't want them to be WebAssembly.Function instances with the associated Wasm types and linking semantics because that would inhibit the optimizations Binaryen can do to the types of functions that can be passed to configureAll

@tlively Can you elaborate on this?

I agree with @jakobkummerow that these could likely just be JS builtin function objects with custom steps. That's how exported wasm function objects are specified today.

[tlively]

But we also don't want them to be WebAssembly.Function instances with the associated Wasm types and linking semantics because that would inhibit the optimizations Binaryen can do to the types of functions that can be passed to configureAll

@tlively Can you elaborate on this?

Actually maybe this is not so important after all. Binaryen benefits a lot from its "closed-world" optimization mode, where it assumes that values flowing out of the instance will not be accessed or inspected in any way besides being passed back into the instance. We already have to slightly amend this to account for function references flowing into configureAll being callable from outside the module, but we would like to continue optimizing the types of those functions. In particular we want to continue to be able to do things like remove unused fields from the receiver types. If the exposed method is a JS method that will use ToWebAssemblyValue and ToJSValue wrappers when linked into other modules, then these optimizations won't break such linking. This is what I had in mind. But the alternative is that we would just have to assume such linking does not happen when optimizing in closed-world mode, which is already our assumption for other function references that escape the module.

[jakobkummerow]

In my previous post, I forgot to mention one important consideration:
If we decided to show the wrappers on stack traces, that would lead to one follow-up question: what function name should be printed for the wrapper? For human readability, it would of course be nice if the wrapper had a name reflecting the name of the object property it is accessing. However, that would have huge performance cost on instantiation (when creating all the wrappers), because then each wrapper would have to store its own name, which would make them significantly more costly to allocate than they currently are in my prototype. (I think I measured the difference weeks ago, but I didn't write down the numbers, so I can't quote them here. They were pretty bad!)
My implementation currently makes the wrappers share as much of their internal representation as possible in order to make it as cheap as possible to mass-produce thousands of them; which is actually similar to what you'd get if you created them in pure JavaScript like in the snippets in the OP. That has the consequence though that all wrappers must have the same name. So if they showed up on stack traces, they could have a name like GenericWasmPropertyAccessor there. But arguably that's not much more useful than just not showing them at all.

[eqrion]

@jakobkummerow If these are wrappers with a common generic name, will the underlying wasm function's name still show up underneath that? If so, then I think a single common name is fine.

[jakobkummerow]

Yes, sure, I'm only talking about the wrapper, which (if it's displayed on stack traces at all) sits between a properly named JS function and a properly named exported Wasm function.

I would still like it if we agreed that it's not a spec violation if the wrappers don't show up on stack traces.

[eqrion]

I would still like it if we agreed that it's not a spec violation if the wrappers don't show up on stack traces.

I agree it's not a spec violation (as there is none). The only concern would be a potential web-compat issue in the future, which seems unlikely, so it seems fine if that's what V8 wishes to do.