• 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
..
Memory.json Loading commit data...
run.js Loading commit data...