tree 9f240342de27b7f2f7ef927276db8d1d5cfb103e
parent a99b92c2525c6e490e2a55fce2888d251688b67a
author Martin Kustermann <kustermann@google.com> 1626338390 +0000
committer commit-bot@chromium.org <commit-bot@chromium.org> 1626338390 +0000

[vm] Move main ObjectStore initialization right after bootstrapping but before loading user classes

This CL fixes AOT failures that happened after [0] landed. That code
removed lookup code for the `future_class()` in the
`ObjectStore::LazyInit*()` methods and replaced it with an assert instead.
The change was correct, since the lazy members should be initialized
on-demand - after the core, non-lazy members.
=> Though this seemed to not be the case in AOT, which hit the assert.

The reason [0] only caused failures in AOT is because in JIT the VM is
bootstrapped only from the vm_platform.dill file and as a secondary
embedder call the application.dill file is loaded.
Yet in AOT we have a combined full_application.dill which will all be
loaded during bootstrapping. That has caused the application to be
loaded before `ObjectStore::InitKnownObjects()` was invoked.

The initialization of [ObjectStore] which contains common core library
classes/functions/fields should happen before we use the kernel loader
to load user classes (since general kernel loading depends on the
[ObjectStore] being populated).

This also ensures that `ObjectStore::InitKnownObjects()` will be called
before `ObjectStore::LazyInit*()` - since they depend on the former having
run (e.g. that the non-lazy `future_class()` member of `ObjectStore`
was set).

[0] https://dart-review.googlesource.com/c/sdk/+/206782

TEST=Fixes AOT builders.

Change-Id: I0861d1a2f39effbcea08d7796742845b874a0084
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207002
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>