This patch removes the concept of reservations and a specialized
deserializer allocator, and instead makes the deserializer allocate
directly with the Heap's Allocate method.
The major consequence of this is that the GC can now run during
deserialization, which means that:
a) Deserialized objects are visible to the GC, and
b) Objects that the deserializer/deserialized objects point to can
move.
Point a) is mostly not a problem due to previous work in making
deserialized objects "GC valid", i.e. making sure that they have a valid
size before any subsequent allocation/safepoint. We now additionally
have to initialize the allocated space with a valid tagged value -- this
is a magic Smi value to keep "uninitialized" checks simple.
Point b) is solved by Handlifying the deserializer. This involves
changing any vectors of objects into vectors of Handles, and any object
keyed map into an IdentityMap (we can't use Handles as keys because
the object's address is no longer a stable hash).
Back-references can no longer be direct chunk offsets, so instead the
deserializer stores a Handle to each deserialized object, and the
backreference is an index into this handle array. This encoding could
be optimized in the future with e.g. a second pass over the serialized
array which emits a different bytecode for objects that are and aren't
back-referenced.
Additionally, the slot-walk over objects to initialize them can no
longer use absolute slot offsets, as again an object may move and its
slot address would become invalid. Now, slots are walked as relative
offsets to a Handle to the object, or as absolute slots for the case of
root pointers. A concept of "slot accessor" is introduced to share the
code between these two modes, and writing the slot (including write
barriers) is abstracted into this accessor.
Finally, the Code body walk is modified to deserialize all objects
referred to by RelocInfos before doing the RelocInfo walk itself. This
is because RelocInfoIterator uses raw pointers, so we cannot allocate
during a RelocInfo walk.
As a drive-by, the VariableRawData bytecode is tweaked to use tagged
size rather than byte size -- the size is expected to be tagged-aligned
anyway, so now we get an extra few bits in the size encoding.
Bug: chromium:1075999
Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70229}
5d7a29c90e