tree 2e32e3beda437e1b95c00e5181c4ab879893eca8
parent 006b3a8780e8630ebcf393606f52868b5de11147
author Martin Kustermann <kustermann@google.com> 1689329706 +0000
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> 1689329706 +0000

[vm] Refactor handling of kernel data in compiler frontend

a) Remove 2 fields in our object representation:

  * PatchClass::library_data_
  * Library::kernel_data_

=> This saves O(#libraries + #patch-classes) which can amount up to
  10+ MB for big apps, as we save not just the slots but the
  [ExternalTypedData] objects they used to reference.

Instead we'll compute the KernelLibraryData when we need it by making a
[TypedDataView] of sub parts of the component.

b) We make a kernel binary be represented by a single [ExternalTypedData].

Whenever we need a sub-part of a kernel binary (e.g. one for each
component for concatinated kernels, or one for a library inside a
component) we use proper [TypedDataView]s for that.

c) As we sometimes need to create a view of only a particular library
within a component we need to find start/end of a library based on
index.

=> We store the library index instead of the library offset on
Library/PatchClass.
=> We can easily derive the start/end of a library from it's index by
looking at the kernel component encoding.

d) We make the [Reader] object work purely based on a pointer - instead
of making it have if/else when reading bytes (either from pointer or
from a view).

e) We make the [KernelProgramInfo] store the kernel_component and
various TD views into it.

TEST=ci

Change-Id: Ibe160881ff48635e834c3d647a977a144b5d0565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313561
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>