.. which traces various stats (time, memory) related to the snapshot.
Due to various flag shuffles, it was broken as of Oct 2020, with some
line items reporting constant 0.

This also refactors --profile-deserialization and
--serialization-statistics s.t. the former only reports
deserialization times and the latter reports memory. Memory.json now
passes both flags.

Change-Id: I7dacbbbe9f7a667e0802d0f7a44703dc34524a4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854742
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74241}

This relands commit 3f4e9bbe.
which was a reland of c4a062a9
which was a reland of 28a30c57
which was a reland of 5d7a29c9

The change had an issue that embedders implementing heap tracing (e.g.
Unified Heap with Blink) could be passed an uninitialized pointer if
marking happened during deserialization of an object containing such a
pointer. Because of the 0xdeadbed0 uninitialized filler value, these
embedders would then receive the value 0xdeadbed0deadbed0 as the
'pointer', and crash on dereference.

There is, however, special handling already for null pointers in heap
tracing, also for dealing with not-yet initialized values. So, we can
make the uninitialized Smi filler be 0x00000000, and that will make such
embedded fields have a nullptr representation, making them follow the
normal uninitialized value bailouts.

In addition, it relands the following dependent changes, which are
relanding unchanged and are followup performance improvements.
Relanding them in the same change should allow for cleaner reverts
should they be needed.

This relands commit 76ad3ab5
[identity-map] Change resize heuristic

This relands commit 77cc96aa
[identity-map] Cache the calculated Hash

This relands commit bee5b996
[serializer] Remove Deserializer::Initialize

This relands commit c8f73f22
[serializer] Cache instance type in PostProcessNewObject

This relands commit 4e7c99ab
[identity-map] Remove double-lookups in IdentityMap

Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a9
> which was a reland of 28a30c57
> which was a reland of 5d7a29c9
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c57
> > which was a reland of 5d7a29c9
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c9
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > 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}

Bug: chromium:1075999
Change-Id: Ib514a4ef16bd02bfb60d046ecbf8fae1ead64a98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452689
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70366}

This reverts commit 3f4e9bbe, along
with the following dependent changes (reverted to make this a clean revert):
76ad3ab5 [identity-map] Change resize heuristic
77cc96aa [identity-map] Cache the calculated Hash
bee5b996 [serializer] Remove Deserializer::Initialize
c8f73f22 [serializer] Cache instance type in PostProcessNewObject
4e7c99ab [identity-map] Remove double-lookups in IdentityMap

Reason for revert: major crash spike on Canary (https://crbug.com/1135027)

Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a9
> which was a reland of 28a30c57
> which was a reland of 5d7a29c9
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c57
> > which was a reland of 5d7a29c9
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c9
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > 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}
> > >
> > > Bug: chromium:1075999
> > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70267}
> >
> > Tbr: jgruber@chromium.org,ulan@chromium.org
> > Bug: chromium:1075999
> > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70279}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
> Bug: chromium:1075999
> Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70288}

TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org

Bug: chromium:1075999, chromium:1135027
Change-Id: I5d0d9e49c0302d94ff7291834f5f18e7a0839eb7
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451030Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70328}

This is a reland of c4a062a9
which was a reland of 28a30c57
which was a reland of 5d7a29c9

Fixes TSAN errors from non-atomic writes in the deserializer. Now all
writes are (relaxed) atomic.

Original change's description:
> Reland^2 "[serializer] Allocate during deserialization"
>
> This is a reland of 28a30c57
> which was a reland of 5d7a29c9
>
> The crashes were from calling RegisterDeserializerFinished on a null
> Isolate pointer, for a deserializer that was never initialised
> (specifically, ReadOnlyDeserializer when ROHeap is shared).
>
> Original change's description:
> > Reland "[serializer] Allocate during deserialization"
> >
> > This is a reland of 5d7a29c9
> >
> > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > to not check the new space addresses until it's known that this is a new
> > space allocation. This fixes an UBSan failure during read-only space
> > deserialization, which happens before the new space is initialized.
> >
> > It also fixes some issues discovered by --stress-snapshot, around
> > serializing ThinStrings (which are now elided as part of serialization),
> > handle counts (I bumped the maximum handle count in that check), and
> > clearing map transitions (the map backpointer field needed a Smi
> > uninitialized value check).
> >
> > 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}
> >
> > Bug: chromium:1075999
> > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70267}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Bug: chromium:1075999
> Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70279}

Tbr: jgruber@chromium.org,ulan@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Bug: chromium:1075999
Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70288}

This reverts commit c4a062a9.

Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33504

Original change's description:
> Reland^2 "[serializer] Allocate during deserialization"
>
> This is a reland of 28a30c57
> which was a reland of 5d7a29c9
>
> The crashes were from calling RegisterDeserializerFinished on a null
> Isolate pointer, for a deserializer that was never initialised
> (specifically, ReadOnlyDeserializer when ROHeap is shared).
>
> Original change's description:
> > Reland "[serializer] Allocate during deserialization"
> >
> > This is a reland of 5d7a29c9
> >
> > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > to not check the new space addresses until it's known that this is a new
> > space allocation. This fixes an UBSan failure during read-only space
> > deserialization, which happens before the new space is initialized.
> >
> > It also fixes some issues discovered by --stress-snapshot, around
> > serializing ThinStrings (which are now elided as part of serialization),
> > handle counts (I bumped the maximum handle count in that check), and
> > clearing map transitions (the map backpointer field needed a Smi
> > uninitialized value check).
> >
> > 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}
> >
> > Bug: chromium:1075999
> > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70267}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Bug: chromium:1075999
> Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70279}

TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org

Change-Id: Ib2f01db4cd9b55639d6a4af971bda865edb45e84
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445250Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70280}

This is a reland of 28a30c57
which was a reland of 5d7a29c9

The crashes were from calling RegisterDeserializerFinished on a null
Isolate pointer, for a deserializer that was never initialised
(specifically, ReadOnlyDeserializer when ROHeap is shared).

Original change's description:
> Reland "[serializer] Allocate during deserialization"
>
> This is a reland of 5d7a29c9
>
> This reland shuffles around the order of checks in Heap::AllocateRawWith
> to not check the new space addresses until it's known that this is a new
> space allocation. This fixes an UBSan failure during read-only space
> deserialization, which happens before the new space is initialized.
>
> It also fixes some issues discovered by --stress-snapshot, around
> serializing ThinStrings (which are now elided as part of serialization),
> handle counts (I bumped the maximum handle count in that check), and
> clearing map transitions (the map backpointer field needed a Smi
> uninitialized value check).
>
> 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}
>
> Bug: chromium:1075999
> Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70267}

Tbr: jgruber@chromium.org,ulan@chromium.org
Bug: chromium:1075999
Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70279}

This reverts commit 28a30c57.

Reason for revert: Broke Test262 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/38638?

Original change's description:
> Reland "[serializer] Allocate during deserialization"
>
> This is a reland of 5d7a29c9
>
> This reland shuffles around the order of checks in Heap::AllocateRawWith
> to not check the new space addresses until it's known that this is a new
> space allocation. This fixes an UBSan failure during read-only space
> deserialization, which happens before the new space is initialized.
>
> It also fixes some issues discovered by --stress-snapshot, around
> serializing ThinStrings (which are now elided as part of serialization),
> handle counts (I bumped the maximum handle count in that check), and
> clearing map transitions (the map backpointer field needed a Smi
> uninitialized value check).
>
> 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}
>
> Bug: chromium:1075999
> Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70267}

TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org

Change-Id: Ieed68332ef6a7ad36db061e3f48be0f28673d7a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441608Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70268}

This is a reland of 5d7a29c9

This reland shuffles around the order of checks in Heap::AllocateRawWith
to not check the new space addresses until it's known that this is a new
space allocation. This fixes an UBSan failure during read-only space
deserialization, which happens before the new space is initialized.

It also fixes some issues discovered by --stress-snapshot, around
serializing ThinStrings (which are now elided as part of serialization),
handle counts (I bumped the maximum handle count in that check), and
clearing map transitions (the map backpointer field needed a Smi
uninitialized value check).

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}

Bug: chromium:1075999
Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70267}

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: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70231}

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}

We have a global test/OWNERS that has "file://COMMON_OWNERS".
This CL removes redundant OWNERS files in test/ subdirectories and
removes redundant entries from OWNERS files we need to keep for
special per-file entries.

R=yangguo@chromium.org, machenbach@chromium.org
CC=​​jkummerow@chromium.org

Bug: v8:9247
Change-Id: Ic2e8cbe8e379d7d23c86c6164305e65807f28ed3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674024Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62336}

Bug: v8:9247
Change-Id: Id6860e7b0f932990ac3cda39e369b0809e4f6a2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632072Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61928}

Until this CL, the Memory benchmark was the only one to be based on a
cctest runner; all others use d8. Besides being a tedious exception to
the rule, this caused issues such as described in the linked bug
(summary: refbuilds are built with v8_static_library, and neither
cctests nor unittests support this configuration).

Here, we move the Memory benchmark into a d8 runner.

Bug: v8:9189, chromium:957029
Change-Id: I9b45ff36f4842cb0bdef2c1c4b0184c5509d3385
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588464
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61245}

Now that lazy deserialization has been removed, we can roll back all
the mechanisms we introduced to support lazy single-builtin
deserialization.

This CL moves serialized builtin code objects (i.e.
off-heap-trampolines in most cases) back into the startup snapshot.
Support classes for builtin serialization and deserialization, as well
as the builtins snapshot itself are removed. Templatization on the
allocator class is removed as well.

Tbr: delphick@chromium.org
Bug: v8:6666, v8:7990
Change-Id: I2a910f8d3278b7e27b5f18ad408361ebd18871cc
Reviewed-on: https://chromium-review.googlesource.com/c/1304539Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57160}

Bug: v8:8329
Change-Id: I5be972698809ca77a621bb960cbc6a23b9f0f4b0
Reviewed-on: https://chromium-review.googlesource.com/c/1296474Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56901}

This adds the option to output statistics about the embedded blob.

On x64 release, the output is currently:

Total size:                         724064
Metadata size:                      6832
Instruction size:                   703427
Padding:                            13805
Embedded builtin count:             852
Instruction size (50th percentile): 222
Instruction size (75th percentile): 749
Instruction size (90th percentile): 1871
Instruction size (99th percentile): 9171

Total size is added to our Memory benchmark.

Drive-by: Fix startup / context regexps for Memory benchmark.

Bug: v8:6666, v8:7898
Change-Id: I90d4458877939d3b48593bd9dd3a33971fe78c44
Reviewed-on: https://chromium-review.googlesource.com/1126104
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54256}

This is a reland of 989285b7

Original change's description:
> [tools] Add benchmark owners to the config
>
> R=machenbach@chromium.org
>
> No-Try: true
> Bug: chromium:826280
> Change-Id: Ic34d13170dfecdd9e791974a34c33ba0248c7a38
> Reviewed-on: https://chromium-review.googlesource.com/1053809
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53138}

TBR=machenbach@chromium.org

No-Try: true
Bug: chromium:826280
Change-Id: I169788ff40dd88a7017b46a15b292568b907f38e
Reviewed-on: https://chromium-review.googlesource.com/1061697
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53215}

This reverts commit 989285b7.

Reason for revert: broke internal bots

Original change's description:
> [tools] Add benchmark owners to the config
> 
> R=​machenbach@chromium.org
> 
> No-Try: true
> Bug: chromium:826280
> Change-Id: Ic34d13170dfecdd9e791974a34c33ba0248c7a38
> Reviewed-on: https://chromium-review.googlesource.com/1053809
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53138}

TBR=machenbach@chromium.org,sergiyb@chromium.org

Change-Id: Iec3f8fa8eda77b1bcfb00274b28a12e4d233d6c4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:826280
Reviewed-on: https://chromium-review.googlesource.com/1057091Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53140}

R=machenbach@chromium.org

No-Try: true
Bug: chromium:826280
Change-Id: Ic34d13170dfecdd9e791974a34c33ba0248c7a38
Reviewed-on: https://chromium-review.googlesource.com/1053809Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53138}

test-serialize/SerializationMemoryStats does not actually create a new
Isolate from scratch. Instead, it deserializes from the snapshot and
we can simply piggy-back off existing output to measure
deserialization time.

Bug: v8:6666,v8:7693
Change-Id: I8f709ea834ff7f5e46f7ebfa9b0c35d96095bf26
Reviewed-on: https://chromium-review.googlesource.com/1039585Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52918}

R=jgruber@chromium.org

Bug: v8:6624
Change-Id: I4929a404999cf4d2c12471d5ee13533234fbcf7e
Reviewed-on: https://chromium-review.googlesource.com/645126Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47730}

R=jochen@chromium.org, vogelheim@chromium.org
BUG=chromium:617892

Review-Url: https://codereview.chromium.org/2055203002
Cr-Commit-Position: refs/heads/master@{#37008}

TBR=machenbach@chromium.org

Review URL: https://codereview.chromium.org/1078353002

Cr-Commit-Position: refs/heads/master@{#27765}

R=machenbach@chromium.org

Review URL: https://codereview.chromium.org/1074143002

Cr-Commit-Position: refs/heads/master@{#27754}

R=machenbach@chromium.org

Review URL: https://codereview.chromium.org/1075143002

Cr-Commit-Position: refs/heads/master@{#27738}