Support for weak entry points in the VM

[mkustermann]

Currently we can mark functions (and other objects) as @pragma('vm:entry-point').

Having this annotation implies currently a number of things:

1. The function serves as a root for our AOT tree shaker (i.e. it's code and what it calls cannot be tree-shaken)
2. The function may be looked up by name (i.e. cannot be obfuscated)
3. The function needs to have it's Function object preserved for AOT runtime (i.e. cannot tree-shake function object)
4. The function's parameter types etc need to be preserved so arguments can be type-checked before invoking the function (i.e. cannot tree-shake function metadata)

There's use cases where we'd only need 2/3/4 but not 1 and as such would allow us to sometimes tree shake chunks of apps away that happen to be unused.

Case for @pragma('vm:weak-entry-point')

Flutter provides an API to map a function to a "unique" integer. When the app later on gets started (e.g. due to an OS event that starts the app) the app can look up based on that unique integer the dart function and call it. More specifically an app can

• call dart:uis PluginUtilities.getCallbackHandle(function)
  • Internally this will use Dart VM runtime-reflection on the function provided to obtain: library/class/function names of the tear-off function - see DartRuntimeHooks::GetCallbackHandle()
  • (The function has therefore to be a global/static function annotated via @pragma('vm:entry-point'))
  • Assign a number to the function (identified by library/class/function name) and write a json file to-disc that maps the integer to the library/class/function names DartCallbackCache::GetCallbackHandle()
• later on call PluginUtilities.getCallbackFromHandle
  • which will end up loading file on disc, looking up the integer, getting library/class/function names, and get the corresponding dart function

Now the interesting thing to note here is that if we have e.g.

void register() {
  if (<always-false>) {
    // Dead code, call will be removed by AOT compiler.
    PluginUtilities.getCallbackHandle(myCallback);
  }
}

void foo() {
  final function = PluginUtilities.getCallbackFromhandle(CallbackHandle.fromRawHandle(123));
  // `function` can never be `myCallback` (since we tree-shaken `PluginUtilities.getCallbackHandle(myCallback)`).
}

@pragma('vm:entry-point')
void myCallback() {
  <lots of things we do here>
}

then we (as application developer) know that myCallback will never be invoked.

To support this use case, we could add a @pramga('vm:weak-entry-point') that will have the same implications as a normal @pragma('vm:entry-point') with the difference that we allow our AOT tree shaker to tree shake it, but if it survived we have to guarantee 2/3/4 above.

/cc @alexmarkov @mraleph

[alexmarkov]

We may be able to achieve the same even without new pragma.

@pragma('vm:entry-point') takes an optional bool argument which can be used to express condition for including this entry point. So, we can probably use the same <always-false> condition in pragma:

@pragma('vm:entry-point', <always-false>).

For example, sometimes we use @pragma('vm:entry-point', !const bool.fromEnvironment("dart.vm.product")) to include something only in the flutter profile mode and exclude in release.

If this <always-false> condition is used to guard platform-dependent code, then we can introduce a series of defines for each OS and CPU to express such conditions.

[mkustermann]

This issue is unrelated to platform-specific tree shaking. I don't believe this can be made with compile-time expression in the annotation. The pattern described in this issue is used by some flutter plugins. So right now as long as the import graph contains a flutter plugin, it's dart code is preserved, even if the app never uses the plugin.

The precise semantics we'd like to have is for any non-tree shaken PluginUtilities.getCallbackHandle(<expr>) call (and other such methods) with <expr> being a top-level function: make us have properties 2-4 above.

An approximating to the above semantics would be a weak entrypoint annotation: if function is used, treat it as entrypoint, if it's not used, tree shake it.