[VM] Remove synthetic mixin application classes and copying of mixin methods

[alexmarkov]

Currently, for each mixin application front-end generates synthetic (anonymous) mixin application class.
Moreover, mixin_full_resolution transformation (pkg/kernel/lib/transformations/mixin_full_resolution.dart) copies members from mixin to each mixin application class.

For example:

class B {}

class M {
  void foo() => print('foo');
}

class A extends B with M {}

Kernel:

  class B extends core::Object {
    synthetic constructor •() → foo::B
      : super core::Object::•()
      ;
  }
  class M extends core::Object {
    synthetic constructor •() → foo::M
      : super core::Object::•()
      ;
    method foo() → void
      return core::print("foo");
  }
  abstract class _A&B&M extends foo::B implements foo::M /*isAnonymousMixin,isEliminatedMixin*/  {
    synthetic constructor •() → foo::_A&B&M
      : super foo::B::•()
      ;
    method foo() → void
      return core::print("foo");
  }
  class A extends foo::_A&B&M {
    synthetic constructor •() → foo::A
      : super foo::_A&B&M::•()
      ;
  }

This results in a large number of extra synthetic classes which increase AOT snapshot size, memory footprint of an application and compilation time.

There are a few mitigations for this problem in Dart VM/AOT:

• mixin_deduplication transformation (pkg/vm/lib/transformations/mixin_deduplication.dart) which removes duplicate mixin application classes if same B with M mixin application is used multiple times. But it cannot eliminate duplication between B1 with M and B2 with M.
• VM deduplicates methods with the same generated machine code, but that doesn't work if generated code is different, for example due to different object pool indices used for caches in distinct copies of mixin methods.

These optimizations help but there is still redundancy left even after all these deduplications.

Instead, we can redesign mixins in the VM, removing mixin application classes and copying of mixin methods entirely.

In such case, super calls will not be resolved at compile time. Instead, they will be dispatched at run time.
For example, we can treat super calls super.foo from class C similarly to interface calls, just with a special selector super:foo@C. Actual classes will have targets for these super: selectors in the dispatch table depending on their superclasses and mixins. Many of those super calls can be devirtualized and converted into direct calls (for example, if a class is not used as a mixin, or if mixin is always used with the same superclass).

Such implementation of mixins should result in a smaller AOT snapshot size, lower memory footprint and faster compilation, with the expense of slightly more expensive super calls. Hopefully the performance difference would be negligible.

/cc @mraleph @mkustermann @rmacnak-google @a-siva

[rmacnak-google]

Agreed. The copy-down implementation of mixins also creates complexity for the debugger, because one function at the language level maps to multiple functions in the implementation and the debugger has to worry about synchronizing breakpoint state, especially copies of the function that show up after the breakpoint is created due to lazy finalization.

Removing the static binding of super calls would also fix incorrect behavior in hot reload that currently exists for some cases. (Extra name mangling isn't necessary, it's enough that the call site has a bit to decide which lookup rule to use.)

Since every class is a mixin application (even if most are the only application of their mixin), the VM's program representation can be cleaned up from Class { superclass, methods, ... } to Class { superclass, mixin, ... } + Mixin { methods, ... }.

[mkustermann]

There are quite possibly performance implications of making the super calls resolve at runtime. One could add a @pragma('vm:...') to get the old duplication behavior for a particular class as an escape hatch.

Maybe the first step here would be to estimate the percentage of AOT code size which we pay for such duplicated mixin functions (measured on one of our big g3 apps) - to see how much the gain there would be.

[mraleph]

Maybe the first step here would be to estimate the percentage of AOT code size which we pay for such duplicated mixin functions (measured on one of our big g3 apps) - to see how much the gain there would be.

+1 to this. We should definitely start by doing an on the napkin calculation to estimate the gain (and maybe loss as well, we can replace super calls with virtual invocations without deduplication to see the performance impact on something like Flutter benchmarks?).