Skip to content

Support AOT splitting #41974

Closed
Closed
Support AOT splitting#41974
Assignees
rmacnak-google
Labels
area-vmUse area-vm for VM related issues, including code coverage, and the AOT and JIT backends.customer-google3vm-aot-code-sizeRelated to improvements in AOT code size
Milestone
February Beta Release

Description

@mehmetf
mehmetf
opened on May 19, 2020

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.

Activity

  1. mehmetf
    added
    area-vmUse area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
    vm-aot-code-sizeRelated to improvements in AOT code size
    on May 19, 2020
  2. a-siva
    assigned
    rmacnak-google
    on May 20, 2020

  3. mraleph commented on May 20, 2020

    @mraleph
    mraleph
    on May 20, 2020
    Member

    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?

  4. mehmetf commented on May 20, 2020

    @mehmetf
    mehmetf
    on May 20, 2020
    ContributorAuthor

    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.

  5. a-siva commented on May 20, 2020

    @a-siva
    a-siva
    on May 20, 2020
    Contributor

    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.

  6. mehmetf commented on May 20, 2020

    @mehmetf
    mehmetf
    on May 20, 2020
    ContributorAuthor

    @chingjun FYI

  7. xster commented on May 28, 2020

    @xster
    xster
    on May 28, 2020
    Contributor

    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.

  8. dart-bot
    added 2 commits that reference this issue on May 28, 2020

    [vm] Check prefix.loadLibrary is called and returns before prefix mem…

    f049a41

    Revert "[vm] Check prefix.loadLibrary is called and returns before pr…

    bbf3403
  9. dart-bot
    added 3 commits that reference this issue on Jun 11, 2020

    [vm] Check prefix.loadLibrary is called and returns before prefix mem…

    b0484ec

    Revert "[vm] Check prefix.loadLibrary is called and returns before pr…

    9a87cf9

    Reland "[vm] Check prefix.loadLibrary is called and returns before pr…

    62893f9

  10. a-siva commented on Jun 18, 2020

    @a-siva
    a-siva
    on Jun 18, 2020
    Contributor

    go/dart-aot-deferred-loading

  11. dart-bot
    added a commit that references this issue on Jun 19, 2020

    [vm] Compute a partitioning of the program into loading units.

    6cc9439

  12. 19 remaining items

  13. dart-bot
    added a commit that references this issue on Oct 30, 2020

    Add tests for the identity of constants repeated in different loading…

    88fdb3e
  14. dart-bot
    added a commit that references this issue on Dec 8, 2020

    [vm] Gracefully handle loads not solicited by prefix.loadLibrary().

    1b160f7
  15. dart-bot
    added 4 commits that reference this issue on Jan 8, 2021

    [vm] Defer object pools.

    0bf8d38

    [vm, gc] Ensure exclusive access to the heap during deserialization.

    784e69a

    [vm, compiler] Fix per-Code ObjectPools to track all the objects used…

    b02cd95

    [vm] Defer object pool entries in instructions bare mode.

    63d17b0
  16. a-siva
    added this to the February Beta Release milestone on Feb 9, 2021
  17. dart-bot
    added a commit that references this issue on Feb 10, 2021

    [vm] Replace recanonicalization in primary snapshots with weak consta…

    25fd020

  18. Cat-sushi commented on Feb 18, 2021

    @Cat-sushi
    Cat-sushi
    on Feb 18, 2021

    IMHO, grapheme clusters(Characters) should be a part of dart:core. (cf. dart-lang/language#1432)
    While Characters has tables 24KB large in total.
    So, this issue might be important for grapheme clusters.

  19. vsmenon commented on Feb 25, 2021

    @vsmenon
    vsmenon
    on Feb 25, 2021
    Member

    @a-siva @rmacnak-google - is there still open work here?

  20. a-siva commented on Feb 25, 2021

    @a-siva
    a-siva
    on Feb 25, 2021
    Contributor

    Yes there is still this CL to land https://dart-review.googlesource.com/c/sdk/+/183781

  21. dart-bot
    added a commit that references this issue on Mar 4, 2021

    [vm] Defer object pools and object pool entries.

    dce0b51

  22. a-siva commented on Mar 8, 2021

    @a-siva
    a-siva
    on Mar 8, 2021
    Contributor

    CLs have landed, closing issue.

  23. a-siva
    closed this as completedon Mar 8, 2021
  24. copybara-service
    added a commit that references this issue on Jun 27, 2022

    Reapply "Account for @pragma("vm:entry-point") creating additional "r…

    93a4247
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area-vmUse area-vm for VM related issues, including code coverage, and the AOT and JIT backends.customer-google3vm-aot-code-sizeRelated to improvements in AOT code size

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions