• Leszek Swirski's avatar
    Revert "[serializer] Allocate during deserialization" · 74f3665c
    Leszek Swirski authored
    This reverts commit 5d7a29c9.
    
    Reason for revert: UBSan -- https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/13100
    
    Original change's description:
    > [serializer] Allocate during deserialization
    >
    > 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}
    
    TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
    
    Change-Id: I2bd792a24861e8f54897e51522769b50f8f814e2
    No-Presubmit: true
    No-Tree-Checks: true
    No-Try: true
    Bug: chromium:1075999
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440827
    Commit-Queue: Leszek Swirski <leszeks@chromium.org>
    Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#70231}
    74f3665c
Name
Last commit
Last update
..
arm Loading commit data...
arm64 Loading commit data...
ia32 Loading commit data...
mips Loading commit data...
mips64 Loading commit data...
ppc Loading commit data...
s390 Loading commit data...
x64 Loading commit data...
OWNERS Loading commit data...
arguments-inl.h Loading commit data...
arguments.cc Loading commit data...
arguments.h Loading commit data...
execution.cc Loading commit data...
execution.h Loading commit data...
external-pointer-table.cc Loading commit data...
external-pointer-table.h Loading commit data...
frame-constants.h Loading commit data...
frames-inl.h Loading commit data...
frames.cc Loading commit data...
frames.h Loading commit data...
futex-emulation.cc Loading commit data...
futex-emulation.h Loading commit data...
interrupts-scope.cc Loading commit data...
interrupts-scope.h Loading commit data...
isolate-data.h Loading commit data...
isolate-inl.h Loading commit data...
isolate-utils-inl.h Loading commit data...
isolate-utils.h Loading commit data...
isolate.cc Loading commit data...
isolate.h Loading commit data...
local-isolate-inl.h Loading commit data...
local-isolate.cc Loading commit data...
local-isolate.h Loading commit data...
messages.cc Loading commit data...
messages.h Loading commit data...
microtask-queue.cc Loading commit data...
microtask-queue.h Loading commit data...
pointer-authentication-dummy.h Loading commit data...
pointer-authentication.h Loading commit data...
protectors-inl.h Loading commit data...
protectors.cc Loading commit data...
protectors.h Loading commit data...
runtime-profiler.cc Loading commit data...
runtime-profiler.h Loading commit data...
simulator-base.cc Loading commit data...
simulator-base.h Loading commit data...
simulator.h Loading commit data...
stack-guard.cc Loading commit data...
stack-guard.h Loading commit data...
thread-id.cc Loading commit data...
thread-id.h Loading commit data...
thread-local-top.cc Loading commit data...
thread-local-top.h Loading commit data...
v8threads.cc Loading commit data...
v8threads.h Loading commit data...
vm-state-inl.h Loading commit data...
vm-state.h Loading commit data...