[dart2wasm] Avoid making every closure needs it's own dynamic call forwarder

[mkustermann]

Currently each closure will get a vtable slot for the dynamic call forwarder. That forwarder takes a list of arguments and a list of named arguments. It then directly calls the target.

We want to avoid paying a code size cost for each closure in the program if there's a single dynamic call user.

I think we can instead make the vtable slot for the dynamic call forwarder contain a function that is shared among all closures that have the same closure representation.

If we do this then that shared dynamic call forwarder cannot directly dispatch to the target function, as we'll have a 1<->N relationship. Though that shared dyn call forward has access to the closure and the vtable. And since it's per-closure-representation cluster we know the layout and entries of the vtable.

That in return means that instead of directly dispatching to the target, it can inspect the number of positional arguments in the array it got and the names it got and then (indirectly) call the corresponding entry in the vtable matching that positional & name combination.

This would possibly remove the majority of dynamic call forwarder functions.

/cc @osa1

[osa1]

I started looking into this.

I think we can instead make the vtable slot for the dynamic call forwarder contain a function that is shared among all closures that have the same closure representation.

When you say closure representation do you include the context type as well?

If you include the context type then I'm not sure if there will be a lot of closures with the same representation, because tear-offs with the same type will have different receivers, and function expressions will have different contexts.

If you don't include the context type, then we need an additional entry point in each vtable that just downcasts the context from ref struct to the right context type. In the case where there aren't a lot of closures with the same number of parameters (with same default values for optional parameters) this can add to the binary size.

Any thoughts @mkustermann?

[mkustermann]

If you don't include the context type, then we need an additional entry point in each vtable that just downcasts the context from ...

Aren't all the closure bodies already downcasting the ref struct to what that particular closure expects?

[mkustermann]

When you say closure representation do you include the context type as well?

By representation I mean the closed-world computation we perform to determine closure clusters based on looking at all closure call sites and closure targets - we group them into compatible groups for which we determine the representation (e.g. vtable entries)

[osa1]

Aren't all the closure bodies already downcasting the ref struct to what that particular closure expects?

Tear-off closure bodies are just methods so they expect the right typed receiver. Example:

class A {
  foo() {
    print("A.foo");
  }
}

bool get runtimeTrue => int.parse('1') == 1;

main() {
  dynamic a = runtimeTrue ? A().foo : "";
  a();
}

The dynamic call entry downcasts from ref struct (the context value from the code you linked) to ref A.

For some reason that I don't understand, for function expressions we seem to do it diffently. Function expression bodies always take a ref struct argument and downcast it in the function body (rather than in vtable entries). If I add this closure to the example above:

a = runtimeTrue ? (() { a(); }) : (() {});
a();

I get this Wasm for the function body:

(func $main closure at file:///usr/local/google/home/omersa/dart/sdk/test/test.dart:33:43 (;272;) (param $var0 (ref struct)) (result nullref)
  (local $var1 (ref $<context file:///usr/local/google/home/omersa/dart/sdk/test/test.dart:21:5>))
  local.get $var0
  ref.cast $<context file:///usr/local/google/home/omersa/dart/sdk/test/test.dart:21:5>
  local.set $var1
  ref.null none
)

Note that it downcasts the context directly.

The dynamic call entry:

(func $closure wrapper at file:///usr/local/google/home/omersa/dart/sdk/test/test.dart:33:43 dynamic call entry (;293;) (param $var0 (ref $#ClosureBase)) (param $var1 (ref $Array<_Type>)) (param $var2 (ref $Array<Object?>)) (param $var3 (ref $Array<Object?>)) (result (ref null $#Top))
  (local $var4 (ref null $BoxedInt))
  local.get $var0
  struct.get $#ClosureBase $field2
  call $main closure at file:///usr/local/google/home/omersa/dart/sdk/test/test.dart:33:43
)

I don't know why this difference exists.

To keep the ref.casts at minimum it makes sense that the method bodies expect the receiver to have the right type.

In function expressions, we always allocate a closure, and the closure struct will have a ref struct as the context (the code you linked). When calling, I don't see any reason why we wouldn't be able to downcast the context in the vtable entries, given that the vtable entries are specific to closures.

That said, if vtable entries downcast that means we need a per-closure vtable entry to downcast to the right type and call the body if we reuse vtable entries. So the current design for function expression closures actually make it easier to share dynamic call vtable entries. I'll try to reuse the dynamic all vtable entries just for function expressions for now to see if it works and makes any big difference in binary sizes.