Support AOT splitting

[mehmetf]

One of our biggest internal clients would like to split their AOT code per country. They plan to release to over 25 countries in the next year or so and some of them (such as NBU) are highly size sensitive. Their current calculations indicate that all countries put together will definitely exceed the minimum size requirements for the strictest countries. Their timeline for release is August/September 2020.

To avoid blocking that release, they would like to be able to ship smaller .so modules on Android and have Play Store deliver a combination of these modules to the user depending on their country. As a first step, these will be install-time only modules (i.e. no dynamically downloaded AOT code).

The request from VM team is two folds:

• Ability to do whole-world compilation but then split the final AOT into multiple independently loadable bundles.
  • It would be important to discuss how we expect apps to mark the boundaries of their bundles.
• Ability to load these bundles into the same isolate seamlessly. Not having to restart the isolate would be ideal. However, since we have all the bundles ahead of time, it is not a requirement.

[mraleph]

It would be important to discuss how we expect apps to mark the boundaries of their bundles.

This bug does not mention this explicitly but as noted on the internal bug - I think it is worth sticking with the language and choose to implement deferred libraries support in the AOT compiler.

If there is no strong arguments why we should choose any other implementation strategy, I suggest we go with that.

Any opinion @rmacnak-google @a-siva @mkustermann?

[mehmetf]

Thanks Slava.

I wanted to dump some of my thoughts here:

• On Android, there's no limit to how many bundles an app can generate. However, there is a limit on how many bundles can be requested by user. Anything more than 5 incurs a heavy penalty as each bundle needs to be its separate APK and resource management gets expensive to the system.
  • How many bundles do we expect this to generate? One .so per deferred "file"?
  • Can bundle boundaries be controlled by the app? For instance, can they say package:foo and package:bar need to be bundled together?
• How does deferred loading work exactly?
  • If I have both: import package:foo/foo.dart deferred and a normal import package:foo/foo.dart, what happens?
  • If I have import package:foo/foo.dart deferred but then import package:foo/bar.dart, what happens?
• Is there a way to enforce deferring? e.g. I have 500kLOC code base and I want to enforce that package:foo is always imported deferred. This is probably a g3 question. @matanlurey
• How do we make sure this also works for debug mode as well? We would not want people to discover that they were not awaiting for a deferred library only in release mode.

Related to last point, we also need to come up with a recommended testing strategy. This is not necessary for the initial release but still critical.

[a-siva]

It would be important to discuss how we expect apps to mark the boundaries of their bundles.

This bug does not mention this explicitly but as noted on the internal bug - I think it is worth sticking with the language and choose to implement deferred libraries support in the AOT compiler.

If there is no strong arguments why we should choose any other implementation strategy, I suggest we go with that.

Any opinion @rmacnak-google @a-siva @mkustermann?

I agree let us first stick to the deferred library support.

[mehmetf]

@chingjun FYI

[xster]

From testing last year, the android_dlopen_ext part seems to be in the 10-20ms ballpark. I think a simpler timing API like basing it off of Dart imports is probably sensible.