Files
sdk/runtime
Martin Kustermann 0ae3368fb6 [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>
2023-07-14 10:15:06 +00:00
..
2023-06-30 14:03:03 +00:00
2023-06-30 14:03:03 +00:00
2023-01-25 14:08:27 +00:00