This reverts commit 3f4e9bbe43, along
with the following dependent changes (reverted to make this a clean revert):
76ad3ab597 [identity-map] Change resize heuristic
77cc96aa48 [identity-map] Cache the calculated Hash
bee5b996aa [serializer] Remove Deserializer::Initialize
c8f73f2266 [serializer] Cache instance type in PostProcessNewObject
4e7c99abda [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 c4a062a958
> which was a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> 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 28a30c578c
> > which was a reland of 5d7a29c90e
> >
> > 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 5d7a29c90e
> > >
> > > 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/+/2451030
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70328}
This change adds a new code generator, which supports a subset of the
instructions supported by the existing CSAGenerator, and instead of
generating CSA it generates runtime C++ code. The new generator is used
to generate a set of Torque macros that return slices to indexed fields.
These new macros should be sufficient to eventually support
Torque-generated field accessors, BodyDescriptors, verifier functions,
and postmortem field inspection in debug_helper.
Bug: v8:7793
Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70313}
This CL extracts weak object worklist related code into separate files
and uses a macro to specify all weak object worklists in a generic way.
The motivation of the refactoring is twofold:
1) We can now enforce that each weak object worklist is updated after
Scavenge. (Forgetting to define the update function causes a link
time error.)
2) The reduced boilerplate will be useful for transitioning to the
new ::heap::base::Worklist.
Change-Id: Ic80a7ccca010c09370d6525f43d78de24192f8ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442624
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70308}
Remove a spurious assert probably introduced by a bad merge that
disallowed RO_SPACE sharing when pointer compression is enabled.
Change-Id: I8a59a242667252dcbb098e5be405ac67a4e01a3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445877
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70290}
This is a reland of c4a062a958
which was a reland of 28a30c578c
which was a reland of 5d7a29c90e
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 28a30c578c
> which was a reland of 5d7a29c90e
>
> 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 5d7a29c90e
> >
> > 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 c4a062a958.
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 28a30c578c
> which was a reland of 5d7a29c90e
>
> 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 5d7a29c90e
> >
> > 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/+/2445250
Reviewed-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 28a30c578c
which was a reland of 5d7a29c90e
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 5d7a29c90e
>
> 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}
This reverts commit 28a30c578c.
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 5d7a29c90e
>
> 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/+/2441608
Reviewed-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 5d7a29c90e
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}
Rename it to Symbolizer because it does exactly that.
Change the SymbolizeTickSample method to return the symbolized state
rather than pass it on to the ProfilesCollection. This makes it easier
to test as now it only relies on the CodeMap provided to it.
Make EntryForVMState a free-floating function as it doesn't rely on
state and then we can avoid importing the StateTag definition in the
header.
Remove the UNREACHABLE from EntryForVMState as the compiler got smarter
and doesn't need it anymore.
Pass the CpuProfilesCollection to SamplingEventsProcessor instead,
as it is now responsible for putting the symbolized samples into the
collection to be sorted into the appropriate profiles.
Change-Id: I104290eff22b7d94a1bd34ba904036badccf4e13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440522
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70248}
This is a reland of 92f815a80d
Safe to reland as-is with task id lifetime fix in
https://chromium-review.googlesource.com/c/v8/v8/+/2437005
Original change's description:
> Reland "[Heap] ScavengerCollector use Jobs."
>
> This is a reland of 9e8c54f830
> Safe to reland as-is with fix in AcquireTaskId
> https://chromium-review.googlesource.com/c/v8/v8/+/2401964
>
> Additional changes are made in the reland:
> -TRACE_GC is be split for background/foreground scope.
> -New IndexGenerator is used for dynamic work assignement.
>
> Original change's description:
> > [Heap] ScavengerCollector use Jobs.
> >
> > No yielding is necessary since the main thread Join()s.
> >
> > max concurrency is determined based on either
> > remaining_memory_chunks_ or global pool size
> > (copied_list_ + promotion_list_)
> >
> > Change-Id: Ie30fa86c44d3224b04df5d79569bce126ce7d96b
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354390
> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69746}
>
> Change-Id: Id9d7a5bf3b2337ae4cf1e76770f4b14ebb8ca256
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399041
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70135}
Change-Id: Id0451b6eca9a125c7695d251d1a7d813e0664dd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432071
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70238}
This reverts commit 5d7a29c90e.
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}
This change moves external pointers into a separate table and turns
external pointers in heap objects into indices into that table.
This CL implements one of two possible ownership models for the table
entries. With this one, every heap object owns its table entries, and
they are allocated when the owning object is allocated. As such, setting
external pointer fields does not require allocation of table entries. On
the other hand, table indices cannot be shared between multiple objects.
This CL does not yet implement freeing of external pointer table
entires. This will later happen by a table garbage collector.
Bug: v8:10391
Change-Id: I4d37785295c25a7d1dcbc9871dd5887b9d788a4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235700
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#70204}
Instead of always inlining the polymorphic map checks, this CL
introduces a builtin to perform these polymorphic map checks
when the IC is monomorphic at compile time.
This reduces the time we spend compiling and code bloat while trading it
for performance.
Bug: v8:10582, v8:9684
Change-Id: I7aea698988f8ead3cbf3f4a836218f53223f0f98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398525
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70200}
There were two problems:
1. v8_builtins_profiling_log_file was not declared in "sources" or
"inputs", so Ninja wouldn't re-run mksnapshot if it changed.
2. v8_builtins_profiling_log_file was passed directly to mksnapshot
without rebasing the path, which makes it awkward and inconsistent
with how most other gn arguments work.
Bug: v8:10470
Change-Id: Id8edba325b867e8d9561d3c76f28e121641d0dd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434103
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70199}
There's no builtin implementation code here, the two functions should
live in builtins.cc.
Change-Id: Ie3cff4f1a22c86984a99a3b5d1b82c0f9f9a1f5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436458
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70196}
This additionally combines --future with all other standard testing
variants.
This also enables using concurrent_marking in status files to skip
tests in this variant.
This also marks a slow test that times out in the new config.
Bug: v8:10875
Change-Id: Id904f6a2c51b814eecfccb523a897de2f5d96f56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423719
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70180}
Control-flow aware allocation has been enabled by default for a long
time now. This removes the unused code paths related to splintering.
R=neis@chromium.org
Bug: v8:10933
Change-Id: I19d9eb448c3912b24a1ad16030e7dd556b13accc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434328
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70172}
This reverts commit 2221f0909b.
Reason for revert: fix in patchset 2
Original change's description:
> Revert "cppgc: Provide jobs support through DefaultPlatform and TestPlatform"
>
> This reverts commit 22c0fc8f2e.
>
> Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8712?
>
> Original change's description:
> > cppgc: Provide jobs support through DefaultPlatform and TestPlatform
> >
> > This CL extends cppgc::DefaultPlatform and TestPlatform to emulate
> > jobs using std::thread and v8::base::Thread respectively.
> > Jobs using these platform do not yield unless the job as been
> > cancelled. Additionally, the job priority is ignored.
> >
> > Bug: chromium:1056170
> > Change-Id: I72db1eef410d2be3d3e5ea7d4ece9e5584a451f2
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416378
> > Commit-Queue: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70139}
>
> TBR=mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
>
> Change-Id: Ic29235e3ab78a1b515a5b14b808e116a1ccffc0f
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432087
> Reviewed-by: Francis McCabe <fgm@chromium.org>
> Commit-Queue: Francis McCabe <fgm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70142}
# Not skipping CQ checks because this is a reland.
Bug: chromium:1056170
Change-Id: Iaa8312da759ab97f646a9fb6144462a115393b5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431666
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70150}
This reverts commit 22c0fc8f2e.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8712?
Original change's description:
> cppgc: Provide jobs support through DefaultPlatform and TestPlatform
>
> This CL extends cppgc::DefaultPlatform and TestPlatform to emulate
> jobs using std::thread and v8::base::Thread respectively.
> Jobs using these platform do not yield unless the job as been
> cancelled. Additionally, the job priority is ignored.
>
> Bug: chromium:1056170
> Change-Id: I72db1eef410d2be3d3e5ea7d4ece9e5584a451f2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416378
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70139}
TBR=mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: Ic29235e3ab78a1b515a5b14b808e116a1ccffc0f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432087
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70142}
This CL extends cppgc::DefaultPlatform and TestPlatform to emulate
jobs using std::thread and v8::base::Thread respectively.
Jobs using these platform do not yield unless the job as been
cancelled. Additionally, the job priority is ignored.
Bug: chromium:1056170
Change-Id: I72db1eef410d2be3d3e5ea7d4ece9e5584a451f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416378
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70139}
This reverts commit 92f815a80d.
Reason for revert: broke tests; see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33395?
Original change's description:
> Reland "[Heap] ScavengerCollector use Jobs."
>
> This is a reland of 9e8c54f830
> Safe to reland as-is with fix in AcquireTaskId
> https://chromium-review.googlesource.com/c/v8/v8/+/2401964
>
> Additional changes are made in the reland:
> -TRACE_GC is be split for background/foreground scope.
> -New IndexGenerator is used for dynamic work assignement.
>
> Original change's description:
> > [Heap] ScavengerCollector use Jobs.
> >
> > No yielding is necessary since the main thread Join()s.
> >
> > max concurrency is determined based on either
> > remaining_memory_chunks_ or global pool size
> > (copied_list_ + promotion_list_)
> >
> > Change-Id: Ie30fa86c44d3224b04df5d79569bce126ce7d96b
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354390
> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69746}
>
> Change-Id: Id9d7a5bf3b2337ae4cf1e76770f4b14ebb8ca256
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399041
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70135}
TBR=ulan@chromium.org,etiennep@chromium.org
Change-Id: I4823c642546b82a9a9c8955151cd8784e4b86bc8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431551
Commit-Queue: Francis McCabe <fgm@chromium.org>
Reviewed-by: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70138}
This is a reland of 64caf2b0b2
Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
>
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
> file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
>
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
>
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}
Bug: v8:7793
TBR: hpayer@chromium.orgjgruber@chromium.org
Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70137}
This is a reland of 9e8c54f830
Safe to reland as-is with fix in AcquireTaskId
https://chromium-review.googlesource.com/c/v8/v8/+/2401964
Additional changes are made in the reland:
-TRACE_GC is be split for background/foreground scope.
-New IndexGenerator is used for dynamic work assignement.
Original change's description:
> [Heap] ScavengerCollector use Jobs.
>
> No yielding is necessary since the main thread Join()s.
>
> max concurrency is determined based on either
> remaining_memory_chunks_ or global pool size
> (copied_list_ + promotion_list_)
>
> Change-Id: Ie30fa86c44d3224b04df5d79569bce126ce7d96b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354390
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69746}
Change-Id: Id9d7a5bf3b2337ae4cf1e76770f4b14ebb8ca256
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399041
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70135}
This reverts commit 64caf2b0b2.
Reason for revert: Seems to be causing a failure:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
>
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
> file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
>
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
>
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}
TBR=jgruber@chromium.org,tebbi@chromium.org
Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70065}
This is to establish a naming rule for Torque-generated files:
- If the file is called foo/bar-tq..., then it is derived from a
file foo/bar.tq
- Otherwise it doesn't belong to a specific .tq file.
So far, we attached -tq to all Torque-generated file names, where it
sometimes corresponded to a .tq file name and sometimes not.
It is not necessary to add -tq to file names to indicate that they are
Torque-generated, since they are already in a directory called
torque-generated, and we always refer to them as
"torque-generated/filename", so there is no confusion even though some
files now have the same name as a corresponding hand-written file, for
example factory.cc.
TBR: hpayer@chromium.org
Bug: v8:7793
Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70060}
This is a manual revert of 67cdacd. Experiments have shown that inline
headers do bring real benefits and we won't be proceeding with inline
header removal.
Bug: v8:10749
Change-Id: Icd3d0b3926d0b7a24edb19d9f177e9c8818abe09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412174
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69915}
Currently is_linux GN variable is set to true on building Chrome OS
but it is planned to be set false. This CL is the preparation to
keep the compatibility.
Bug: chromium:1110266
Test: Built locally.
Change-Id: Ibb9a57269f5a147e372fd33a473d9514379e1c68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405847
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69870}
This is a reland of f25cb50a2f
Removed the problematic tests.
The problem with the test was that we try to pop from an empty segment.
GCC flags that as accessing beyond the array (i.e. index is uint16_t
equivalent of -1). Preceding the actual pop is a DCHECK that asserts
the segment isn't empty. In practice, since we have the DCHECK and
access to the segment is always via a Local, this shouldn't be a
problem.
Unfortunately, GCC flags the access regardless. The DCHECK goes through
a function pointer so GCC cannot determine that in our unittest the
DCHECK would crash if index is 0 and the access would not happen (The
indirection was added to allow for test DCHECK handlers that don't
crash, so we can't mark the function pointer as noreturn).
Drive-by: Segment::Pop and Segment::Push rely on the their Local
counterparts checking of emptiness/fullness, so we should always
access segments via Locals. Making the Segment ctor private.
Original change's description:
> Reland "cppgc, heap: Don't eagerly allocate worklist segments"
>
> This is a reland of c99147c65e
>
> Original change's description:
> > cppgc, heap: Don't eagerly allocate worklist segments
> >
> > Bug: chromium:1056170
> > Change-Id: I75a6b5f52bfe8dd71abc086e5d1e060759ad7fc0
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391254
> > Commit-Queue: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69778}
>
> Bug: chromium:1056170
> Change-Id: I4633da065976a6b2710d2f23b946fd2af0e65c83
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401425
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69806}
Bug: chromium:1056170
Change-Id: I7a122d1a2d20cd4e7c824d249975b4d3df30e03e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403251
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69829}
Apple's upcoming arm64 devices will prevent rwx access to memory,
but in turn provide a new per-thread way to switch between write
and execute permissions. This patch puts that system to use for
the WebAssembly subsystem.
The approach relies on CodeSpaceWriteScope objects for now. That
isn't optimal for background threads (which could stay in "write"
mode permanently instead of toggling), but its simplicity makes
it a good first step.
Background:
https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
Bug: chromium:1117591
Change-Id: I3b60f0efd34c0fed924dfc71ee2c7805801c5d42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378307
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69791}
tools/debug_helper:run_mkgrokdump used to only depend on mkgrokdump.
However, the snapshot can change without affecting the mkgrokdump
binary itself. So, if the mkgrokdump binary doesn't change, then
run_mkgrokdump doesn't run, even if the snapshot changed.
This could cause mysterious test failures in incremental builds, in
particular for tests testing the contents of heap-constants-gen.cc.
Now, we make run_mkgrokdump depend on run_mksnapshot_default
directly, so that snapshot updates force an mkgrokdump run.
Change-Id: Ia3871e1b4fa15ec2dbc0bc5463afdb427cb39c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400987
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69776}
This CL migrates cppgc to use Ulan's new worklist implementation.
Since there is no central segments array anymore, we cannot rely on
getting the same view (now renamed to Local) given the same task id.
To avoid creating many short lived segments (e.g. for write barriers)
marking state now holds local views for all worklists and provides
access to them.
Bug: chromium:1056170
Change-Id: Id19fe1196b79ed251810e91074046998dc2a9177
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390771
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69767}
This adds a global counter for the various reasons we might fail to
attribute a tick.
The counters are cleared and printed when Profile::Print() is called,
which we call in our tests, so flaky test output will now contain these
stats along with the printed profile tree.
Drive-by cleanup some print functions and make them const.
Change-Id: Ia3a27405f5b5346adfdbb32afc7e414857969cc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550406
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69647}
When enabled with the v8_enable_conservative_stack_scanning flag, a
snapshot of the call stack upon entry to GC is used to determine part of
the root-set. When the collector walks the stack, it looks at each value
and determines whether it could be a potential on-heap object pointer.
This is very experimental. For conservative stack scanning to work,
direct handles must be implemented.
Bug: v8:10614
Change-Id: Id4209cfbe76ef02239c903fabcb7f677b32fc977
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375201
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69644}
With conservative stack scanning enabled, a snapshot of the call stack
upon entry to GC will be used to determine part of the root-set. When
the collector walks the stack, it looks at each value and determines
whether it could be a potential on-heap object pointer. However, unlike
with Handles, these on-stack pointers aren't guaranteed to point to the
start of the object: the compiler may decide hide these pointers, and
create interior pointers in C++ frames which the GC doesn't know about.
The solution to this is to include an object start bitmap in the header
of each page. Each bit in the bitmap represents a word in the page
payload which is set when an object is allocated. This means that when
the collector finds an arbitrary potential pointer into the page, it can
walk backwards through the bitmap until it finds the relevant object's
base pointer. To prevent the bitmap becoming stale after compaction, it
is rebuilt during object sweeping.
This is experimental, and currently only works with inline allocation
disabled, and single generational collection.
Bug: v8:10614
Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69615}
Schedule is simpler compared to the schedule in blink since it now
returns deadlines based on marked bytes instead of time.
If marking is ahead of schedule, return the minimum step size.
Otherwise, set step size to catch up to schedule (ignoring the time
passed while performing the step).
No more default initial step size (needed in blink since marking speed
was unknown).
If estimated schedule is exceeded (marking takes longer than 500ms), the
steps will try to mark all remaining objects but would still be capped
by the maximum step duration of 2ms.
Bug: chromium:1056170
Change-Id: I09857db161c621a12d064f9c8c21b646c34f9d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375200
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69602}
ppc and s390 do not currently support this feature.
Change-Id: I5ea840e20f9aa77d63d19652bd826c812caae0b4
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366762
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69511}
When CFI is enabled this adds a check against this list whenever a new
return address must be set in a deoptimized frame, as a mitigation for
ROP attacks.
The list is known at linking time so that its content and the pointer
to it can be stored in a read-only memory section.
The check is performed in the signing function, which is no longer
generic, as well as when setting the current pc of the frame.
Since the pc is now only signed when setting the caller's pc, there
is no need for ReplaceContext anymore.
Bug: v8:10026
Change-Id: I5e85a62b94722051716fdeba476db383c702a318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287490
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Cr-Commit-Position: refs/heads/master@{#69478}
Prior versions of GN had a bug (gn:22) where visibility rules
for configs weren't being enforced properly.
This CL tweaks the visibility settings of some configs to
conform to the latest version.
Change-Id: Ic5d827a1f2774278d3894f67fe52bfca836c0409
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360909
Commit-Queue: Dirk Pranke <dpranke@google.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69463}
This adds the new JsRegExp::Type EXPERIMENTAL, which should eventually
be implemented with the algorithm based on automata. Currently the new
engine deals with plain search strings only, i.e. regexps that do not
contain operators or escape sequences.
R=jgruber@chromium.org
Bug: v8:10765
Change-Id: I6a10d9cdf4605d219dbe7cc1989df3bfa7349ff8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339094
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69442}
This is a reland of f4548e7598
Original change's description:
> [regalloc] Place spill instructions optimally
>
> Design doc:
> https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
>
> Most of this change follows directly what is discussed in the design
> document. A few other things are also changed:
>
> - PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
> that it can make use of the decision regarding whether a value is
> spilled at its definition or later.
> - SpillSlotLocator is removed. It was already somewhat confusing,
> because the responsibility for marking blocks as needing frames was
> split: in some cases they were marked by SpillSlotLocator, and in
> other cases they were marked by CommitSpillsInDeferredBlocks. With
> this change, that split responsibility would become yet more
> confusing if we kept SpillSlotLocator for the values that are spilled
> at their definition, so I propose a simpler rule that whatever code
> adds the spill move also marks the block.
> - A few class definitions (LiveRangeBound, FindResult,
> LiveRangeBoundArray, and LiveRangeFinder) are moved without
> modification from register-allocator.cc to register-allocator.h so
> that we can refer to them from another cc file.
>
> Bug: v8:10606
> Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69345}
Bug: v8:10606
Change-Id: I10fc1ef4b0bebb6c9f55ebdefe33e8c1e5646f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352483
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69427}
Enable logging script events and code position events during a
background compile. This isn't technically thread-safe, but neither
are the existing logger accesses in the parser, so something has to
be done here in general.
Bug: chromium:1011762
Change-Id: I3b610c3bb146880ef826928b6f341f402ca6247e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162853
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69426}
This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.
LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).
This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.
Bug: chromium:1011762
Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
ArrayBufferTracker was superseded by ArrayBufferList and
ArrayBufferSweeper. Now that ArrayBufferSweeper is used in production,
we can remove the unused ArrayBufferTracker mechanism.
Bug: v8:10064
Change-Id: I479169c76b6c5c634672024f77e689bb64a36504
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69351}
This reverts commit f4548e7598.
Reason for revert: Breaks some gap resolver tests:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/24204
Original change's description:
> [regalloc] Place spill instructions optimally
>
> Design doc:
> https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
>
> Most of this change follows directly what is discussed in the design
> document. A few other things are also changed:
>
> - PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
> that it can make use of the decision regarding whether a value is
> spilled at its definition or later.
> - SpillSlotLocator is removed. It was already somewhat confusing,
> because the responsibility for marking blocks as needing frames was
> split: in some cases they were marked by SpillSlotLocator, and in
> other cases they were marked by CommitSpillsInDeferredBlocks. With
> this change, that split responsibility would become yet more
> confusing if we kept SpillSlotLocator for the values that are spilled
> at their definition, so I propose a simpler rule that whatever code
> adds the spill move also marks the block.
> - A few class definitions (LiveRangeBound, FindResult,
> LiveRangeBoundArray, and LiveRangeFinder) are moved without
> modification from register-allocator.cc to register-allocator.h so
> that we can refer to them from another cc file.
>
> Bug: v8:10606
> Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69345}
TBR=rmcilroy@chromium.org,seth.brenith@microsoft.com,thibaudm@chromium.org
Change-Id: Ie57109a009ee7ee541a6ff6f89901d1ac99027d2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2350440
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69347}
Design doc:
https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
Most of this change follows directly what is discussed in the design
document. A few other things are also changed:
- PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
that it can make use of the decision regarding whether a value is
spilled at its definition or later.
- SpillSlotLocator is removed. It was already somewhat confusing,
because the responsibility for marking blocks as needing frames was
split: in some cases they were marked by SpillSlotLocator, and in
other cases they were marked by CommitSpillsInDeferredBlocks. With
this change, that split responsibility would become yet more
confusing if we kept SpillSlotLocator for the values that are spilled
at their definition, so I propose a simpler rule that whatever code
adds the spill move also marks the block.
- A few class definitions (LiveRangeBound, FindResult,
LiveRangeBoundArray, and LiveRangeFinder) are moved without
modification from register-allocator.cc to register-allocator.h so
that we can refer to them from another cc file.
Bug: v8:10606
Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69345}
This is the first step in refactoring Worklist to allow arbitrary
number of local worklists with private segments:
- Introduce MarkingWorklistImpl<> which will eventually replace
(and will be renamed to) Worklist.
- MarkingWorklistImpl<> owns the global pool of segments but does not
keep track of private segments.
- MarkingWorklistImpl<>::Local owns private segments and can be
constructed dynamically on background threads.
- Rename the existing MarkingWorklistsHolder to MarkingWorklists.
- Rename the existing MarkingWorklists to MarkingWorklists::Local.
- Rename the existing marking_workists_holder to marking_worklists.
- Rename the existing marking_worklists to local_marking_worklists.
Design doc: https://bit.ly/2XMtjLi
Bug: v8:10315
Change-Id: I9da34883ad34f4572fccd40c51e51eaf50c617bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2343330
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69330}
Changes the isolate's string table into an off-heap structure. This
allows the string table to be resized without allocating on the V8 heap,
and potentially triggering a GC. This allows existing strings to be
inserted into the string table without requiring allocation.
This has two important benefits:
1) It allows the deserializer to insert strings directly into the
string table, rather than having to defer string insertion until
deserialization completes.
2) It simplifies the concurrent string table lookup to allow resizing
the table inside the write lock, therefore eliminating the race
where two concurrent lookups could both resize the table.
The off-heap string table has the following properties:
1) The general hashmap behaviour matches the HashTable, i.e. open
addressing, power-of-two sized, quadratic probing. This could, of
course, now be changed.
2) The empty and deleted sentinels are changed to Smi 0 and 1,
respectively, to make those comparisons a bit cheaper and not
require roots access.
3) When the HashTable is resized, the old elements array is kept
alive in a linked list of previous arrays, so that concurrent
lookups don't lose the data they're accessing. This linked list
is cleared by the GC, as then we know that all threads are in
a safepoint.
4) The GC treats the hash table entries as weak roots, and only walks
them for non-live reference clearing and for evacuation.
5) Since there is no longer a FixedArray to serialize for the startup
snapshot, there is now a custom serialization of the string table,
and the string table root is considered unserializable during weak
root iteration. As a bonus, the custom serialization is more
efficient, as it skips non-string entries.
As a drive-by, rename LookupStringExists_NoAllocate to
TryStringToIndexOrLookupExisting, to make it clearer that it returns
a non-string for the case when the string is an array index. As another
drive-by, extract StringSet into a separate header.
Bug: v8:10729
Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
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@{#69270}
This is a reland of 408e7240d7
Change: Allow CSA load elimination accross code comments
Original change's description:
> [torque] typed context slot access
>
> This introduces a new type Slot<ContextType, SlotType> that is used
> for enum values used to access context slots.
> Together with new types for the various custom contexts used in
> Torque, this results in fairly type-safe access to context slots,
> including the NativeContext's slots.
>
> Drive-by changes:
> - Introduce a new header file to specify headers needed for
> generated CSA headers, to reduce the amount of includes specified
> in implementation-visitor.cc
> - Port AllocateSyntheticFunctionContext to Torque.
>
> Bug: v8:7793
> Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#69249}
Bug: v8:7793
Change-Id: I1fe100d8d62e8220524eddb8ecc4faa85219748d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339462
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69264}
This reverts commit 408e7240d7.
Reason for revert: debug builds fail
is_component_build = true
is_debug = true
use_goma = true
v8_enable_backtrace = true
v8_enable_debugging_features = true
v8_enable_fast_mksnapshot = true
v8_enable_slow_dchecks = true
v8_enable_snapshot_code_comments = true
v8_enable_verify_csa = true
v8_optimized_debug = false
v8_use_multi_snapshots = false
# Fatal error in ../../src/compiler/backend/instruction-selector.cc, line 3088
# Expected Turbofan static assert to hold, but got non-true input:
static_assert(nativeContext == LoadNativeContext(context)) at src/builtins/promise-resolve.tq:45:5
Original change's description:
> [torque] typed context slot access
>
> This introduces a new type Slot<ContextType, SlotType> that is used
> for enum values used to access context slots.
> Together with new types for the various custom contexts used in
> Torque, this results in fairly type-safe access to context slots,
> including the NativeContext's slots.
>
> Drive-by changes:
> - Introduce a new header file to specify headers needed for
> generated CSA headers, to reduce the amount of includes specified
> in implementation-visitor.cc
> - Port AllocateSyntheticFunctionContext to Torque.
>
> Bug: v8:7793
> Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#69249}
TBR=tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: I90c014022a808449aca4a9b9b3c3b8e036beb28e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340903
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69256}
This introduces a new type Slot<ContextType, SlotType> that is used
for enum values used to access context slots.
Together with new types for the various custom contexts used in
Torque, this results in fairly type-safe access to context slots,
including the NativeContext's slots.
Drive-by changes:
- Introduce a new header file to specify headers needed for
generated CSA headers, to reduce the amount of includes specified
in implementation-visitor.cc
- Port AllocateSyntheticFunctionContext to Torque.
Bug: v8:7793
Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69249}
With the new Turbofan variants (NCI and Turboprop), we need a way to
distinguish between them both during and after compilation. We
initially introduced CompilationTarget to track the variant during
compilation, but decided to reuse the code kind as the canonical spot to
store this information instead.
Why? Because it is an established mechanism, already available in most
of the necessary spots (inside the pipeline, on Code objects, in
profiling traces).
This CL removes CompilationTarget and adds a new
NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
various things about a given code kind (e.g.: does this code kind
deopt?).
As a (very large) drive-by, refactor both Code::Kind and
AbstractCode::Kind into a new CodeKind enum class.
Bug: v8:8888
Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69244}
This allows the configuration v8_enable_shared_ro_heap and
v8_enable_pointer_compression on Linux and Android, although it still
defaults to off.
When pointer compression and read-only heap sharing are enabled, sharing
is achieved by allocating ReadOnlyPages in shared memory that are
retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are
then remapped into the address space of the Isolate ultimately using
mremap.
To simplify the creation process the ReadOnlySpace memory for the first
Isolate is created as before without any sharing. It is only when the
ReadOnlySpace memory has been finalized that the shared memory is
allocated and has its contents copied into it. The original memory is
then released (with PC this means it's just released back to the
BoundedPageAllocator) and immediately re-allocated as a shared mapping.
Because we would like to make v8_enable_shared_ro_heap default to true
at some point but can't make this conditional on the value returned by
a method in the code we are yet to compile, the code required for
sharing has been mostly changed to use ifs with
ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where
a compile error would result due to the absence of a class members
without sharing. IsReadOnlySpaceShared() will evaluate
CanAllocateSharedPages in the platform PageAllocator (with pointer
compression and sharing enabled) once and cache that value so sharing
cannot be toggled during the lifetime of the process.
Bug: v8:10454
Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69174}
This is a reland of 13141c8a65
... with a fix for an UB issue of passing null pointers to memcpy()
when size is zero.
TBR=leszeks@chromium.org
Original change's description:
> [zone-compr] Introduce ZoneTypeTraits and ZoneCompression
>
> Also move zone compression flags to src/common/globals.h.
>
> Bug: v8:9923
> Change-Id: Id0a77720e735e2669a1e5eef48e1b4866ad99480
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324255
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69160}
Bug: v8:9923
Change-Id: I2245b81516c39ccea262c282c659ef601af57abf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332165
Commit-Queue: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Reviewed-by: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69166}
As an experiment to see how performance is impacted when changing
inline definitions to normal definitions in a .cc file, this CL moves
js-function-inl.h to js-function.cc.
Bug: v8:10749
Change-Id: I97c3a0b7d20217f444c6891442bbe3c34f3b0cc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315993
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69091}
https://tc39.es/proposal-intl-segmenter/
TC39 passed Intl.Segmenter to stage 3 in Jul 21.
This CL move our earlier prototype to the current spec.
Bug: v8:6891
Change-Id: I07234beed54f671c26bdbfb3983c5bc2fa5a29b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219413
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69080}
These functions match on specific patterns of shuffle that have more
optimized implementations. Moving them out of instruction-selector
allows us to reuse them in Liftoff. Most of these pattern matching
functions do not depend on InstructionSelector, since they work on byte
arrays. (The only one is CanonicalizeShuffle, which swaps node inputs.)
This is only the first pass of moving those functions out. In particular
we can clean things up more by moving the tests out of
instruction-selector as well. Those will come in follow-up changes.
Bug: v8:10696
Change-Id: I4a4333cd8c0259875a672179e72d34dad5f7a008
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308057
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69051}
* Added GN flag v8_enable_zone_compression.
* AccountingAllocator supports allocation of zone segments via both
malloc/free and bounded page allocator. The latter implementation is
known to be not efficient yet. This issue will be addressed in a
follow-up CLs.
* Add support_compression flag to Zone constructor/instance.
Bug: v8:9923
Change-Id: I12ee2d85267dd16f455b1b47edc425dc90c57bcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308345
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69035}
A small step for a JSFunction, one giant leap for V8.
Tbr: clemensb@chromium.org
Bug: v8:8888
Change-Id: I968bb819763994ec611cde7e502adea30339a387
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315979
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69018}
Adds the first phase of the fast register allocator, which runs through
the instruction stream and defines a VirtualRegisterData for each
virtual register based on how that virtual register is produced. Also
adds logic to pipeline.cc to allocate and use FastRegistorAllocatorData
for use throughout the fast register allocation phases.
BUG=v8:9684
Change-Id: I2f4533467346d5f3fdf50a0a1fedd7e4082f0187
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69010}
Design doc:
https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
V8 can already collect data about how many times each basic block in the
builtins is run. This change enables using that data for profile-guided
optimization. New comments in BUILD.gn describe how to use this feature.
A few implementation details worth mentioning, which aren't covered in
the design doc:
- BasicBlockProfilerData currently contains an array of RPO numbers.
However, this array is always just [0, 1, 2, 3, ...], so this change
removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
ensures that the removal is valid.
- RPO numbers, while useful for printing data that matches with the
stringified schedule, are not useful for matching profiling data with
blocks that haven't been scheduled yet. This change adds a new array
of block IDs in BasicBlockProfilerData, so that block counters can be
used for PGO.
- Basic block counters need to be written to a file so that they can be
provided to a subsequent run of mksnapshot, but the design doc doesn't
specify the transfer format or what file is used. In this change, I
propose using the existing v8.log file for that purpose. Block count
records look like this:
block,TestLessThanHandler,37,29405
This line indicates that block ID 37 in TestLessThanHandler was run
29405 times. If multiple lines refer to the same block, the reader
adds them all together. I like this format because it's easy to use:
- V8 already has robust logic for creating the log file, naming it to
avoid conflicts in multi-process situations, etc.
- Line order doesn't matter, and interleaved writes from various
logging sources are fine, given that V8 writes each line atomically.
- Combining multiple sources of profiling data is as simple as
concatenating their v8.log files together.
- It is a good idea to avoid making any changes based on profiling data
if the function being compiled doesn't match the one that was
profiled, since it is common to use profiling data downloaded from a
central lab which is updated only periodically. To check whether a
function matches, I propose using a hash of the Graph state right
before scheduling. This might be stricter than necessary, as some
changes to the function might be small enough that the profile data is
still relevant, but I'd rather err on the side of not making incorrect
changes. This hash is also written to the v8.log file, in a line that
looks like this:
builtin_hash,LdaZeroHandler,3387822046
Bug: v8:10470
Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69008}
... behind --trace-zone-type-stats flag.
Per-object-type statistics requires the following GN args:
v8_enable_precise_zone_stats = true
use_rtti = true
When precise zone stats is enabled, the used zone memory value is
calculated more precisely, in particular it takes into account
the state of the active segment. By default, the used memory in
the active segment is not taken into account because of performance
overhead.
Bug: v8:10572
Change-Id: I938d9e264cfe6a8b63a89db87d187d8e2be63c8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2281006
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68972}
In preparation for AllocationObserver changes, move AllocationObserver
related code into its own file.
Bug: v8:10315
Change-Id: I65d5a51662ff192c7b05d4229d8ca27f4a53aa3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304580
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68924}
This CL ports MarkingVerifier from blink.
The existing verifier checks only references on heap.
This new verifier checks references both on heap and on stack.
Bug: chromium:1056170
Change-Id: I083dcb0087125312cca34a2201015a9aecfe6ea4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300484
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68891}
Adds basic framework to pipeline.cc to enable a seperate fast register
allocator for the TurboProp mid-tier. As part of this, common logic as
well as a base class for RegisterAllocationData is moved to a seperate
register-allocation.h header file. The current register allocator's
RegisterAllocationData is renamed to TopTierRegisterAllocationData, and
the former name is the new base class held in PipelineData.
BUG=v8:9684
Change-Id: I28285b7d6112505bf90e88ea3cda66d03dfabc74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295359
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68852}
This CL adds functionality to read the source positions directly
from the JS heap rather than from serialized data.
In order to do this, we create a PersistentHandles container in the
OptimizedCompilationInfo which gets passed onto the JSHeapBroker. This
allows us to create the handles in the main thread and pass them safely
to the background thread.
In order to read safely from the background thread, we need a LocalHeap
which blocks the GC from running and potentially moving the handles.
This LocalHeap is created only when the JSHeapBroker has finalized
serializing and destroyed when retiring it.
Bug: v8:7790
Change-Id: I19f8b08d12e5be0a3df34d6af2043310c0c7b6fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2277802
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68836}
.. and move all SharedFunctionInfo implementations from objects.cc to
the dedicated shared-function-info.cc.
Drive-by: Also move remaining JSRegExp impls.
Bug: v8:8888
Change-Id: I59adc3928f379eeb8b70f26d7e51d01c889c9a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292240
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68832}
Also make ScopedList class Zone-agnostic and move it to src/utils.
Bug: v8:10506
Change-Id: Ibf0869566caa767809bdf95cb03c01e599613938
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292234
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68825}
This CL removes the GetTraceDescriptor virtual call from garbage
collected mixins and replaces it with querying the object start
bitmap.
The CL also removes the mixin macros which are now no longer needed.
Bug: chromium:1056170
Change-Id: I27ed299f93025d09a3bb3f0d17b14bed3c200565
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287508
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68787}
Instead allocating the bitmap with malloc, we now reserve a block
at the start of the memory chunk. This CL is a partial revert of
https://chromium-review.googlesource.com/c/v8/v8/+/1254125
Additionally it refactors field offset computation and moves them
to MemoryChunkLayout.
Having the bitmap in the memory chunk simplifies sharing of RO pages
and also solves the malloc fragmentation issues.
Bug: chromium:1073140
Change-Id: Ibc04f48921fc9496370858ce4c25c56b31c93c89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2289979
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68783}
PersistentHandles::NewHandle/LocalHeap::NewPersistentHandle currently
erase the type of the object. This patch templatizes them to preserve
the type and introduces versions that take Handle<T>
Bug: v8:10315
Change-Id: I899179a5b842b7b16144b340f6cd2b91e1db228f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287501
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68779}
- Adds JSVisitor that is used for unified heap marking.
- Adds JSMember as supported reference type that also encapsulates a
write barrier in future. JSMember is a replacement for
TracedReference which can be deprecated with EmbedderHeapTracer once
the library is used to handle unified heap collections.
The dispatch for v8::JSMember on cppgc::Visitor is provided through a
specialization of TraceTrait.
Bug: chromium:1056170
Change-Id: I60d976ae66db3e5fa2e690a21627bdcb8c6871af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284488
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68716}
This moves marking write barrier related functions from Heap and
IncrementalMarking into a separate class: MarkingBarrier.
Additionally, a new WriteBarrier class is added at the heap API level
that dispatches to MarkingBarrier.
Future CLs will move slots recording in MarkingBarrier and apply
the same refactoring to the generational barrier. An instance of
MarkingBarrier will be added to each LocalHeap and enable it to
emit a write barrier from a background thread.
Bug: v8:10315
Change-Id: Icc147b48563d88c85d99ead99b1e201f523721d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280083
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68703}
Split off MarkingWorklists and from Marker and introduce MarkerBase.
MarkerBase refers just to interfaces types for passing along visitors.
The concrete Marker provides the impl for these interfaces. Unified
heap marker uses different marking visitors internally but provides an
implementation for the same interface.
Change-Id: Ibc4b2c88e2e69bd303a95da7d167a701934f4a07
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270539
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68676}
Split off MarkingState from MarkingVisitor.
With this CL the marking implementation is moved to "MarkingState"
which is the new bottleneck for marking a single object.
MarkingVisitor merely forwards to MarkingState, which knows how to set
the markbit and add the object to the worklist accordingly. This
allows to have a "UnifiedHeapMarkingVisitor" in future which can
easily reuse Marking to provide C++ marking.
Change-Id: I87ebbe37e8e8cd841e872cae9dc3490e2b55c4dd
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270172
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68660}
Whether or not a store requires a write barrier depends on several
invariants within V8. Some flags can break these invariants. In
particular, it's not possible to use enable_single_generation with
incremental marking because marking barriers are omitted in places where
it is assumed an object will be allocated in the young generation.
This CL introduces a new flag, enable_unconditional_write_barriers,
which allows us to specify that full write barriers should always
happens. The main purpose of this is to support single generation GC
with incremental marking, but it can also aid as a debugging tool to
check for missed write barriers.
Bug: v8:10614
Change-Id: I3ab640436bcefc118c9c5c34765421cb9ea4896f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270546
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jake Hughes <jakehughes@google.com>
Cr-Commit-Position: refs/heads/master@{#68623}
The interpreter is not used in production code any more, hence move it
from src/wasm to test/common/wasm.
It's still used in unit tests, cctests, and in fuzzers.
Because of this move, a few more methods had to be exported via
V8_EXPORT_PRIVATE.
R=ahaas@chromium.org, yangguo@chromium.org
Bug: v8:10389
Change-Id: If626b940a721146c596fd7df4faaea633e710272
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257226
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68480}
This allows the implementation of different stack scanning mechanisms in
V8 (e.g. conservative scanning) while re-using the stack walking API.
Change-Id: I9b9c3b8ffe5d527ca3f7105776821776b509b187
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238194
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68457}
This is a reland of 539f0ed23b
The reland fixes creating TimeDelta from double which requires
saturated_cast<>. Improvements to this constructions are tracked
in v8:10620.
Original change's description:
> cppgc,heap: Implement atomic unified heap GC
>
> Add v8::CppHeap as an implementation of a cppgc heap that
> integrates with V8's existing EmbedderHeapTracer API. The
> current implementation only supports non-incremental marking.
>
> Bug: chromium:1056170
> Change-Id: I4a09eb5ae57f5c7defe35eb3fe346627eb492473
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245610
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68374}
Bug: chromium:1056170,v8:10620
Change-Id: I39e15790e5cafe24da2a14d0bae6543391ebb536
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248191
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68387}
... for nci code, in which several phases of the compiler are not
active:
LowerJSCreateCatchContext
LowerJSCreateEmptyLiteralObject
LowerJSCreateIterResultObject
LowerJSCreateWithContext
LowerJSGetIterator
LowerJSGetTemplateObject
With this change, the nci variant passes the test suite. Tests
relying on turbofan-specific behavior (e.g. deopts) are skipped.
Bug: v8:8888
Change-Id: I709178241e9b25e7480a39b4fb64bdcf576483be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245604
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68381}
This adds the following things:
- age table for 4K regions;
- generational barrier for mixed 4K regions;
- unmarking for major collections;
- young generation flags.
Bug: chromium:1029379
Change-Id: Ief1229f0dac5f90c5f06d3168c8ffb4b7d1f1b53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246566
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68379}
Add v8::CppHeap as an implementation of a cppgc heap that
integrates with V8's existing EmbedderHeapTracer API. The
current implementation only supports non-incremental marking.
Bug: chromium:1056170
Change-Id: I4a09eb5ae57f5c7defe35eb3fe346627eb492473
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245610
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68374}
Since the registration requires calling into the library, there's no
reason to get the heap through a magic getter on API level.
Bug: chromium:1056170
Change-Id: I8d2b1d0fcee8c855908bd26c71a22826c493ed29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238568
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68315}
Unified heap support in V8 requires having another (at least internal)
heap that implements a unfied garbage collection strategy. This will
not re-use the already existing cppgc::Heap because there should be no
way in creating such a heap externally or scheduling stand-alone
garbage collections.
In order to have a common token, this CL introduces AllocationHandle
which can be passed to MakeGarbageCollected to allocate C++ objects.
V8 (soon) and the stand-alone heap both have methods to retrieve such
a handle.
This works around a problem with creating diamond class hierarchies
when a base class would be exposed on the public API level.
Fast paths for Blink are still possible because allocation handles can
be cached the same way (e.g. global, or TLS) as a heap can be cached.
Tbr: yangguo@chromium.org
Bug: chromium:1056170
Change-Id: I8e9472a2c24ef82d1178953e8429b1fd8a2344bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238027
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68310}
Adds allocation-based heap growing strategy that triggers GC based on
some limit. The limit is computed based on previous live memory and a
constant growing factor.
For invoking GC, we support two modes: with and without conservative
stack scanning. Without conservative stack scanning, an invoker makes
sure that we schedule a GC without stack using the existing platform.
Bug: chromium:1056170
Change-Id: I1808aeb5806a6ddd5501b556d6b6b129a85b9cda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228887
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68235}
Changes:
- Remove subtyping checks from value-type.h and move them to dedicated
files. Leave a limited version in value-type.h for testing.
- Implement subtyping for struct and array types, according to the
wasm-gc proposal.
- Implement type equivalence checking.
- Introduce a subtyping relation cache in WasmModule.
- Rename IsSubTypeOf -> IsSubtypeOf.
- Fix v8 possible bug where iterator_range took two unused type
parameters.
- Add unittests for subtyping.
Bug: v8:7748
Change-Id: I0ddbda4145e0412196dcf4fc63f3c5875fb3ab5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228497
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68192}
The flag will be used to upload changes towards the removal of
arguments adaptor frame, by reversing the JS arguments in the stack.
Change-Id: Ia41f740d9fac51a072487733d387390e69574cfb
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2230525
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68176}
This ports HeapStatsCollector (former ThreadHeapStatsCollector) from
Blink. The CL only ports accounting of allocated object size which is
needed for a simple growing strategy in a follow up.
HeapStatsCollector is a global dependency for most sub components as
it provides infrastructure for measuring time (through trace scopes)
and space.
The general idea of HeapStatsCollector is to act as sink where all sub
components push time and space information. This information is then
gathered and made available via an event that is implemented as POD.
Time-dependent info is available through regular getters (pull) and
observers (push).
Change-Id: I40b4d76e1a40c56e5df1a7353622318cde730e26
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225902
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68150}
1) Rename remembered-set-inl.h back to remembered-set.h
2) Introduce a new remembered-set-inl.h and move the
function definition that depends on ptr-compr-inl.h.
Change-Id: I0e16e1e428937184ff255471937c70e6bb65a11e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2223816
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68146}
... in order to make it possible to collect zone memory usage stats
from Chrome.
Drive-by-cleanup: move TracingFlags definition to a separate file.
Bug: v8:10572
Change-Id: I05fb65e207d573d5c18821067cfff4c37f2d77cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2226561
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68135}
This moves several fields that will be needed by ReadOnlySpace pages
when it stops using MemoryChunk into BasicMemoryChunk.
Additionally AllocationStats is moved from spaces.h into
allocation-stats.h.
Bug: v8:10473, v8:10454
Change-Id: I76a66565a260126e629bd7588a5418267dfa8423
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228722
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68134}
Fuzzilli is open source fuzzer by Samuel Groß (saelo@google.com)
that can be used to find bugs in v8 javascript engine. As we want
to automate fuzzing for current versions of v8, we want to merge
fuzzilli toolkit into v8 code, so that fuzzer can automatically
update to the newest version.
So far Fuzzilli has been maintained at
https://github.com/googleprojectzero/fuzzilli .
Bug tracker Id: https://bugs.chromium.org/p/v8/issues/detail?id=10571
Change-Id: I83ddc7e8bb31664c19e4044395bb9044a1c12031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201760
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68132}
This change adds more granular control to the behavior that was
previously controlled by the single flag --turbo-profiling. With this
change, it becomes possible to:
- output information only about builtins, ignoring functions compiled at
runtime
- skip the very slow process of writing the schedule and disassembly for
all builtins, if you only want the block counts and don't need verbose
output
This change also moves the output step from Shell::OnExit to
Isolate::DumpAndResetStats so that it's more consistent with other
features and works in hosts other than d8.
Bug: v8:10470, v8:9119
Change-Id: I19b1caca3ff27a2e4a6fdc7ad2f8174f8d678b3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216717
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68104}
This CL is an initial attempt to reuse BoundedPageAllocator for cppgc.
The caged 4GB heap is needed for:
- fast implementation of the generational barrier;
- potential pointer compression project for Oilpan.
Bug: chromium:1029379
Change-Id: Idfb0ab92c988e2045d4a0e9746bedf841d66e282
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215818
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68074}
This CL adds the new _WithFeedback variant of unary, binary, and
compare operation builtins. Existing logic to do these operations is
refactored s.t. it can be used by both ignition bytecode handlers and
the new builtins.
Note that the new builtins are not yet used. Follow-up CLs will hook
them into generic lowering.
Bug: v8:8888
Change-Id: Id77dbe74bdf3b3806b2aefdf1abe52c3d165a3a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208862
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67956}
This CL introduces the SyncStreamingDecoder to support
streaming compilation when --single-threaded is set. The
SyncStreamingDecoder buffers all bytes it receives over
{OnBytesReceived}, and compiles them synchronously upon {Finish}.
In addition to introducing SyncStreamingDecoder, this CL does
the following changes:
* Redirect streaming compilation to the new streaming decoder if
--no-wasm-async-compilation is set. This flag is set if
--single-threaded is set.
* Extend the test-streaming-compilation.cc tests to test also the new
streaming decoder.
R=thibaudm@chromium.org
Bug: v8:10548
Change-Id: I807e291a6060067c9835de4adf82bcb00321d995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209053
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67955}
Currently, if d8 is run with the --turbo-profiling flag, it prints info
about every TurboFan-compiled function. This info includes the number of
times that each basic block in the function was run. It also includes
text representations of the function's schedule and code, so that the
person reading the output can associate counters with blocks of code.
The data about each function is currently stored in a
BasicBlockProfiler::Data instance, which is attached to a list owned by
the singleton BasicBlockProfiler. Each Data contains an
std::vector<uint32_t> which represents how many times each block in the
function has executed. The generated code for each block uses a raw
pointer into the storage of that vector to implement incrementing the
counter.
With this change, if you compile with v8_enable_builtins_profiling and
then run with --turbo-profiling, d8 will print that same info about
builtins too.
In order to generate code that can survive being serialized to a
snapshot and reloaded, this change uses counters in the JS heap instead
of a std::vector outside the JS heap. The steps for instrumentation are
as follows:
1. Between scheduling and instruction selection, add code to increment
the counter for each block. The counters array doesn't yet exist at
this point, and allocation is disallowed, so at this point the code
refers to a special marker value.
2. During finalization of the code, allocate a BasicBlockProfilingData
object on the JS heap containing data equivalent to what is stored in
BasicBlockProfiler::Data. This includes a ByteArray that is big
enough to store the counters for each block.
3. Patch the reference in the BuiltinsConstantsTableBuilder so that
instead of referring to the marker object, it now refers to this
ByteArray. Also add the BasicBlockProfilingData object to a list that
is attached to the heap roots so it can be easily accessed for
printing.
Because these steps include modifying the BuiltinsConstantsTableBuilder,
this procedure is only applicable to builtins. Runtime-generated code
still uses raw pointers into std::vector instances. In order to keep
divergence between these code paths to a minimum, most work is done
referring to instances of BasicBlockProfiler::Data (the C++ class), and
functions are provided to copy back and forth between that type and
BasicBlockProfilingData (the JS heap object).
This change is intended only to make --turbo-profiling work consistently
on more kinds of functions, but with some further work, this data could
form the basis for:
- code coverage info for fuzzers, and/or
- hot-path info for profile-guided optimization.
Bug: v8:10470, v8:9119
Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67944}
This allows embedding objects in each other and recursively trace
through them.
Bug: chromium:1056170
Change-Id: I4e4ae4c1669109c01003cb6b69797cf271a74033
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198977
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67841}
Splits out all of SemiSpace, NewSpaces and related classes into
paged-spaces.h.
Bug: v8:10473, v8:10506
Change-Id: I97ecceaf5df41263cc8ea75ff0018442bfeffa66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202903
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67831}
Splits out all of PagedSpace and subclasses into paged-spaces.h. Also
moves CodeObjectRegistry to code-object-registry.h.
Bug: v8:10473, v8:10506
Change-Id: I35fab1e545e958eb32f3e39a5e2ce8fb087c2a53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201763
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67811}
This CL adds 2 new values to the EmbedderStackState enum with more
explicit names. The old values are updated as aliases to the new
values and marked as soon to be deprecated. This CL also moves the
enum to v8-platform.h so that it can be reused by cppgc.
Depracating individual values in an enum is supported by GCC only
since version 6. Thus new macros were needed for the deprecation
(which delegate to the existing macros when supported). GCC versions
older than 6 are still used by the CQ bots.
Bug: chromium:1056170
Change-Id: Id1ea73edfbbae282b0d8a3bb103dbbbf8ebd417e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2188971
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67744}
We are currently porting Chromium over to use the Perfetto client
library for tracing[1]. When this mode is enabled, V8 should also use
the Perfetto library built by Chromium instead of building an
indepedendent copy. This patch enables that behavior, gated by the
|use_perfetto_client_library| flag set by Chromium.
We also roll Perfetto to the latest version, add a couple of missing
dependencies on v8_tracing and add a missing tracing category group.
[1] https://docs.google.com/document/d/1f7tt4cb-JcA5bQFR1oXk60ncJPpkL02_Hi_Bc6MfTQk/
(Internal) Bug: 155075662
Change-Id: I76d9626b1c83cb7a278dc3281b3a1db653ab8733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182637
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67706}
Collecting feedback for {Call,InstanceOf,Construct} is similar
but distressingly different. In preparation for adding a
CollectConstructFeedback helper, this CL ports {Call,InstanceOf}
feedback collection to Torque.
Bug: v8:8888
Change-Id: Iaacc137ef46a77a4fe2857ec41c5cc30614dfdf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187497
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67703}
This patch provides infrastructure to pin object types to specific
spaces. This allows embedders to create mutual exclusive arenas for
certain (base) types. In future, this will also be used to provide
sliding-window compaction on certain custom spaces.
We mainly preserve the existing infrastructure with the difference
that spaces are now slightly more dynamic than in Blink as they are
kept in a vector instead of a fixed-size array.
The mechanism differs from Blink in that it does not allow the user
object to call allocation methods directly but instead provides a
trait that can be overridden to specify a custom space.
The patch preserves templatization for objects that do not go into
custom spaces to safe a branch in the allocation hot path.
Change-Id: I08aa6932348e2d6258e19c4a32d189865f459f02
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187611
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67666}
In upcoming work these flags will be used to configure the
experimental native context independent code feature.
Build-time flags:
v8_enable_nci_code
Defines:
V8_ENABLE_NCI_CODE
Runtime flags:
--turbo-nci
--turbo-nci-as-highest_tier
--print-nci-code
--trace-turbo-nci
Drive-by: Remove unused embedded builtins and jitless defines.
Bug: v8:8888
Change-Id: I4466b440634a787bd84b052fe2466b22540216a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184295
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67650}
This CL introduces:
- Worklist
- MarkingHandler to manage gc marking phase
- Integration into CollectGarbage for atomic pause GC
- MarkingVisitor for main thread marking
Still missing from this CL:
- Proper handling for stack scanning
- Handling of previously not fully constructed objects
Bug: chromium:1056170
Change-Id: I70ac8534dfb898777cf3a06e3119cac8072174fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170526
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67642}
Allow cleared references to be created with an OffThreadIsolate.
This includes allowing isolate_root to be accessed from the
OffThreadIsolate, for pointer decompression.
Bug: chromium:1075999
Change-Id: I62e0fe2c1c6166a7b816593ae1ec5ddb1c25d861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183911
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67599}
This ports sweeper logic from Blink into a separate entity - Sweeper.
Concurrent sweeping is in a followup.
Bug: chromium:1056170
Change-Id: I41196225f0d882cb0ab5190d23e297ee2498df6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2167858
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67581}
- Port WasmTableGet, WasmTableSet, and WasmRefFunc to Torque.
- Breaks WasmBuiltinsAssembler into .cc and .h files.
Change-Id: I0f62715ce10beedabf7b4f9502c9476de9efdd5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2175090
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67575}
Also makes memory-chunk.h accessible from outside heap which allows
removal of some heap-inl.h includes.
Bug: v8:10473, v8:10496
Change-Id: Iec4fc5ce8ad201f6ee5fd924cc3cd935324429fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172088
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67551}
Summary of changes:
- GC visitors no longer rely on superclass visitors, but instead visit
everything themselves. This enables generating better code.
- Try to match simple body descriptors to reduce the amount of generated
code.
- Turn SizeFor(instance) into an AllocatedSize() method.
- Remove the special handling of resizable object sizes from Torque
and instead overwrite AllocatedSize in classes that need special
handling in C++.
- Split the visitor id lists depending on whether the class has pointer
fields.
- Turn Torque-generated body descriptors into an .inc file to
simplify includes.
- Fix generated size functions to properly align the size.
- Generate GC visitors (and C++ class definitions) for all string
classes and FixedArray, WeakFixedArray, and WeakArrayList.
- Store generated instance types in Torque class types. This is only
used to determine if a type has a single instance type in this CL.
Bug: v8:7793
Change-Id: I4d362e96b047c305bd6d065247734957b8958c42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67542}
Moves ReadOnlyPage, ReadOnlyArtifacts, ReadOnlySpace and
SharedReadOnlySpace out of spaces.h and into read-only-spaces.h, as well
as creating a corresponding .cc file.
Bug: v8:10473
Change-Id: I9d8b49d61ed643fd6e16919d571a909ab6fce407
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2171197
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67531}
When a background thread fails to allocate, it requests a GC and
retries the allocation afterwards. Make second allocation more likely
to succeed by allowing those allocations to expand the old space.
TLABs of LocalHeaps also need to be invalidated before the GC.
Bug: v8:10315
Change-Id: Idaea2c4ee25642d508c72ae274b06d60c6e225e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154193
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67496}
The worklist in this CL is a merge of the worklists of Oilpan and V8. This implementation supports both use cases and should serve as the shared worklist once we start merging the codebase.
Bug: chromium:1056170
Change-Id: I4ecdb475f3900c33eced9249efa112a69c1b2707
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170828
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67459}
HeapVisitor is a simple visitor implementing both visitation and accept
interfaces. HeapVisitor is aimed to replace functions that traverse the
heap in Blink: PrepareForSweep, Sweep, FinalizeSweep, MakeConsistentForGC,
ObjectPayloadSize, VerifyObjectStartBitmap, CollectStatistics, etc.
This CL also introduces a Heap::ObjectPayloadSize function.
Bug: chromium:1056170
Change-Id: I85a2b8b572486bea29704fc436b002d8f7405201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165733
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67458}
Creates a new large-spaces.h and large-spaces.cc to contain
LargeObjectSpace and subclasses.
Bug: v8:10473
Change-Id: Ifdb4eac9df5c8213f992d549e04b612b62f6df0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170826
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67456}
base::List is only used inside of heap and has some pretty strange
semantics that don't lend themselves to it being a general purpose data
structure so this moves it to heap where it can be safe isolated.
Bug: v8:10454
Change-Id: I7921c22286276432956005c72143b22b0364fc93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170029
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67448}
This adds the following:
1) Heap object structure classes: RawHeap, BaseArena and BasePage.
- freelist
- linear allocation block
2) ObjectAllocator, a class responsible for object (and page) allocation.
The design doc with UML design: https://bit.ly/2VVTcqc
User defined arenas are followup.
Bug: chromium:1056170
Change-Id: I69a82974bd08e3cf3da90041b1628297cc890891
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2167392
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67425}
This changelist makes the GDB-stub actually execute GDB-remote commands, by
accessing the Wasm engine state. More precisely:
- class GdbServer registers DebugDelegates that receive debug notifications when
a new Wasm module is loaded, when execution suspends at a breakpoint or for an
unhandled exception.
- Since the GDB-remote commands arrive on a separate thread, all
queries from the debugger are transformed into Task objects, that are posted
into a TaskRunner that runs in the Isolate thread.
- class WasmModuleDebug contains the logic to retrieve the value of globals, locals, memory ranges from the
Wasm engine and to add/remove breakpoints.
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Test with: python tools\run-tests.py --outdir=out\debug_x64 debugging -j 1
Bug: chromium:1010467
Change-Id: I9703894620a027d3c920926db92e2ff809d84ab8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941139
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#67412}
The impl works by posting up to NumberOfWorkerThreads() tasks
with CallOnWorkerThread().
Change-Id: I188ac57c9e5d6e3befdcc6f945fbf337dabe1d1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2130886
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67368}
Now that PartialSerializer/Deserializer/etc have been renamed to
ContextSerializer/ContextDeserializer/etc, the files can now be renamed
hopefully leaving the full history available in code search.
Bug: v8:10416
Change-Id: I266c915f6d01a7e2913c4d34d9913fa551046dc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144061
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67333}
- implemented as a single-linked list with head and tail
pointers. The tail pointer is needed for freelist appending;
- stores entries in buckets, where bucket[log2(size)] stores
entries >= size;
- implements worst fit allocation to amortize free list call;
- ported from Blink: https://bit.ly/2yC8XKJ.
Bug: chromium:1056170
Change-Id: I26cf62c948c95a7cbfecd5f7f22ad975e6b8c732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157376
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67310}
Provide a stub `third_party_heap::Heap` implementation to work around
linker erors with Visual Studio.
cl.exe in debug mode seems to eliminate dead code not as aggressively
as clang or gcc, resulting in references to `third_party_heap::Heap`
remaining in unreachable code paths.
Refs: https://github.com/bnoordhuis/v8-cmake/issues/10
Bug: v8:10427
Change-Id: I61fde11697adc663b182f60c132eda435a7f11bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159490
Commit-Queue: Ben Noordhuis <info@bnoordhuis.nl>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67293}
This moves:
- ExternalReferenceEncoder to codegen/external-reference-encoder.h
- SerializerDeserializer to snapshot/serializer-deserializer.h
- Checksum() to snapshot/snapshot-utils.h
serializer-common.h and .cc are removed.
Tbr: clemensb@chromium.org,ulan@chromium.org
Bug: v8:10416
Change-Id: I36a242dcc1ad8833374aa567f73e0d4a75632c58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144118
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67281}
snapshot.h is intended to be the public header for the snapshot
component, and not the right place for private declarations. This moves
them into a new SnapshotImpl class in snapshot.cc (previously named
snapshot-common.cc).
Bug: v8:10416
Change-Id: If34ad8d6e189050686942488fb8e99c3d310beee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144062
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67279}
- Fixes includes to be relative to include/ which allows embedders
to just add V8's include directory to get started.
- Adds public target for the library as "cppgc".
Bug: chromium:1056170
Change-Id: Iec9b644e20016a5d7281275b739821a050fd2540
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157366
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67278}
Refactors out the allocation and space merging parts of OffThreadFactory
into a new OffThreadHeap class. This allows a separation of concerns
between allocating/merging and initializing, and future-proofs the
factory code against off-thread allocation implementation changes (e.g.
LocalHeap).
Bug: chromium:1011762
Change-Id: I876906dbfd50f8aafe56af2e63e5fe35e4f7f8e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157369
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67270}
The intent of this work is to create a clean interface header file for
the snapshot component. As a first step, move SerializedData and
SnapshotData into their own dedicated files.
Bug: v8:10416
Change-Id: I95af08508555a2ec3c2364094b81a76e3e6bb38a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144117
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67269}
Port several CLs recorded in bug 9909.
We test this on 3A4000, and find many issues in MSA implement, but they are not related with this patch, will fix in another CL.
Looks like there is no 32-bit os for 3a4000, so we do not implements s128 for mips32.
Bug: v8:9909
Change-Id: Iad7569ebb92904bae66d420c8306cde24afb034a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147575
Commit-Queue: Yu Yin <xwafish@gmail.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67259}
This patch adds a new category group for v8.gc + devtools and adds a
missing dependency on Perfetto's generated headers.
Bug: chromium:1006766
Change-Id: Id92fdc0b938d25ab0df5ada936d3f987cc6ec5f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2156767
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67239}
This patch replaces V8's tracing implementation (i.e., the TRACE_EVENT
macros) with the track event base implementation from Perfetto. The
advantages of doing this are:
1) This allows us to remove most tracing-related backend code from V8.
2) V8 can start writing strongly typed trace event arguments, which
are more compact, easier to process and more extensible than legacy
JSON-based trace arguments.
For the time being, we still support the old trace macros when V8 is
embedded into Chrome and other embedders.
Design doc: https://docs.google.com/document/d/1f7tt4cb-JcA5bQFR1oXk60ncJPpkL02_Hi_Bc6MfTQk/edit#heading=h.398p6b4eaen2
Bug: chromium:1006766
Change-Id: Ie71474fbe065821772b13d851487ebbca680c4ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947688
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67217}
This changelist adds the logic to format, decode, sends and receive packets in
the format specified by the GDB-remote protocol
(https://sourceware.org/gdb/onlinedocs/gdb/Overview.html#Overview).
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Bug: chromium:1010467
Change-Id: Ibc9c6713c561d06847b472fab591c208c193199f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929409
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67196}
Adds an pure (not inline) assembly version of
PushAllRegistersAndIterateStack for the Microsoft Arm Assembler, which
uses slightly different syntax.
Bug: v8:10407
Change-Id: I539e2021bd86e17a2d023c061c9753b4bd96ce2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150600
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67177}
To avoid shrinking the unregister token map on each pop of the cleared
cell list, the Torque implementation of the cleanup loop avoids
shrinking the map until the end of the loop.
To support that, PopClearedCellHoldings is refactored to the Torque
PopClearedCell which calls the
JSFinalization::RemoveCellFromUnregisterTokenMap and the runtime
ShrinkFinalizationRegistryUnregisterTokenMap. The former cannot GC is
and is implemented in CSA as a fast C call. The latter can GC and is a
runtime call.
This also incidentally makes uses of FinalizationRegistry without
unregister token a fast path that doesn't have to leave Torque.
Bug: v8:8179
Change-Id: Ia0c3c5800d26e31319a818f164f6bd3267355aa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137950
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67161}
Add ConcurrentAllocator which can be used for concurrent allocation from a background thread in the old space. ConcurrentAllocator doesn't request a GC yet when an allocation fails. This will be implemented in later CLs.
Bug: v8:10315
Change-Id: I81260ebbd8863c143e93aedb93c66d0e7c28bddb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144066
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67150}
A few notes:
1) Oilpan is a generic library, meaning that it can work with arbitrary
user types. The library is split in type-aware (include/) and
type-erased (src/) parts. The former comprises a lot of code that still
needs to be defended with dchecks;
2) Macros are prefixed with CPPGC_, so that they don't clash in the user
code with similar macros from other libraries;
3) The macros simply forward requests to V8 so that dcheck handlers can
be configured uniformly;
4) The CL doesn't contain CHECK_EQ and friends, but they can be added
later if needed.
Bug: chromium:1056170
Change-Id: I68e6f663247705233eaf030384164d81e53071e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148774
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67129}
