- 14 May, 2021 1 commit
-
-
Shu-yu Guo authored
This option is used for --stress-snapshot when sharing the RO heap. The RO heap is shared, so deserializing non-startup snapshots need to ensure they use the same RO object cache mapping as the startup snapshot. Cq-Include-Trybots: luci.v8.try:v8_linux64_gc_stress_custom_snapshot_dbg_ng Bug: v8:11750 Change-Id: Ia2baa24d5b7d494ef5b7ff3c9cbcee846881182e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897945Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74574}
-
- 09 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I9d6925e8e68f4a0e71a10ec39d10ae306f9efcbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2524413Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71030}
-
- 07 Oct, 2020 1 commit
-
-
Leszek Swirski authored
This relands commit 3f4e9bbe. which was a reland of c4a062a9 which was a reland of 28a30c57 which was a reland of 5d7a29c9 The change had an issue that embedders implementing heap tracing (e.g. Unified Heap with Blink) could be passed an uninitialized pointer if marking happened during deserialization of an object containing such a pointer. Because of the 0xdeadbed0 uninitialized filler value, these embedders would then receive the value 0xdeadbed0deadbed0 as the 'pointer', and crash on dereference. There is, however, special handling already for null pointers in heap tracing, also for dealing with not-yet initialized values. So, we can make the uninitialized Smi filler be 0x00000000, and that will make such embedded fields have a nullptr representation, making them follow the normal uninitialized value bailouts. In addition, it relands the following dependent changes, which are relanding unchanged and are followup performance improvements. Relanding them in the same change should allow for cleaner reverts should they be needed. This relands commit 76ad3ab5 [identity-map] Change resize heuristic This relands commit 77cc96aa [identity-map] Cache the calculated Hash This relands commit bee5b996 [serializer] Remove Deserializer::Initialize This relands commit c8f73f22 [serializer] Cache instance type in PostProcessNewObject This relands commit 4e7c99ab [identity-map] Remove double-lookups in IdentityMap Original change's description: > Reland^3 "[serializer] Allocate during deserialization" > > This is a reland of c4a062a9 > which was a reland of 28a30c57 > which was a reland of 5d7a29c9 > > Fixes TSAN errors from non-atomic writes in the deserializer. Now all > writes are (relaxed) atomic. > > Original change's description: > > Reland^2 "[serializer] Allocate during deserialization" > > > > This is a reland of 28a30c57 > > which was a reland of 5d7a29c9 > > > > The crashes were from calling RegisterDeserializerFinished on a null > > Isolate pointer, for a deserializer that was never initialised > > (specifically, ReadOnlyDeserializer when ROHeap is shared). > > > > Original change's description: > > > Reland "[serializer] Allocate during deserialization" > > > > > > This is a reland of 5d7a29c9 > > > > > > This reland shuffles around the order of checks in Heap::AllocateRawWith > > > to not check the new space addresses until it's known that this is a new > > > space allocation. This fixes an UBSan failure during read-only space > > > deserialization, which happens before the new space is initialized. > > > > > > It also fixes some issues discovered by --stress-snapshot, around > > > serializing ThinStrings (which are now elided as part of serialization), > > > handle counts (I bumped the maximum handle count in that check), and > > > clearing map transitions (the map backpointer field needed a Smi > > > uninitialized value check). > > > > > > Original change's description: > > > > [serializer] Allocate during deserialization > > > > > > > > This patch removes the concept of reservations and a specialized > > > > deserializer allocator, and instead makes the deserializer allocate > > > > directly with the Heap's Allocate method. > > > > > > > > The major consequence of this is that the GC can now run during > > > > deserialization, which means that: > > > > > > > > a) Deserialized objects are visible to the GC, and > > > > b) Objects that the deserializer/deserialized objects point to can > > > > move. > > > > > > > > Point a) is mostly not a problem due to previous work in making > > > > deserialized objects "GC valid", i.e. making sure that they have a valid > > > > size before any subsequent allocation/safepoint. We now additionally > > > > have to initialize the allocated space with a valid tagged value -- this > > > > is a magic Smi value to keep "uninitialized" checks simple. > > > > > > > > Point b) is solved by Handlifying the deserializer. This involves > > > > changing any vectors of objects into vectors of Handles, and any object > > > > keyed map into an IdentityMap (we can't use Handles as keys because > > > > the object's address is no longer a stable hash). > > > > > > > > Back-references can no longer be direct chunk offsets, so instead the > > > > deserializer stores a Handle to each deserialized object, and the > > > > backreference is an index into this handle array. This encoding could > > > > be optimized in the future with e.g. a second pass over the serialized > > > > array which emits a different bytecode for objects that are and aren't > > > > back-referenced. > > > > > > > > Additionally, the slot-walk over objects to initialize them can no > > > > longer use absolute slot offsets, as again an object may move and its > > > > slot address would become invalid. Now, slots are walked as relative > > > > offsets to a Handle to the object, or as absolute slots for the case of > > > > root pointers. A concept of "slot accessor" is introduced to share the > > > > code between these two modes, and writing the slot (including write > > > > barriers) is abstracted into this accessor. > > > > > > > > Finally, the Code body walk is modified to deserialize all objects > > > > referred to by RelocInfos before doing the RelocInfo walk itself. This > > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate > > > > during a RelocInfo walk. > > > > > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > > > > size rather than byte size -- the size is expected to be tagged-aligned > > > > anyway, so now we get an extra few bits in the size encoding. > > > > > > > > Bug: chromium:1075999 > > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#70229} Bug: chromium:1075999 Change-Id: Ib514a4ef16bd02bfb60d046ecbf8fae1ead64a98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452689 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70366}
-
- 05 Oct, 2020 1 commit
-
-
Adam Klein authored
This reverts commit 3f4e9bbe, along with the following dependent changes (reverted to make this a clean revert): 76ad3ab5 [identity-map] Change resize heuristic 77cc96aa [identity-map] Cache the calculated Hash bee5b996 [serializer] Remove Deserializer::Initialize c8f73f22 [serializer] Cache instance type in PostProcessNewObject 4e7c99ab [identity-map] Remove double-lookups in IdentityMap Reason for revert: major crash spike on Canary (https://crbug.com/1135027) Original change's description: > Reland^3 "[serializer] Allocate during deserialization" > > This is a reland of c4a062a9 > which was a reland of 28a30c57 > which was a reland of 5d7a29c9 > > Fixes TSAN errors from non-atomic writes in the deserializer. Now all > writes are (relaxed) atomic. > > Original change's description: > > Reland^2 "[serializer] Allocate during deserialization" > > > > This is a reland of 28a30c57 > > which was a reland of 5d7a29c9 > > > > The crashes were from calling RegisterDeserializerFinished on a null > > Isolate pointer, for a deserializer that was never initialised > > (specifically, ReadOnlyDeserializer when ROHeap is shared). > > > > Original change's description: > > > Reland "[serializer] Allocate during deserialization" > > > > > > This is a reland of 5d7a29c9 > > > > > > This reland shuffles around the order of checks in Heap::AllocateRawWith > > > to not check the new space addresses until it's known that this is a new > > > space allocation. This fixes an UBSan failure during read-only space > > > deserialization, which happens before the new space is initialized. > > > > > > It also fixes some issues discovered by --stress-snapshot, around > > > serializing ThinStrings (which are now elided as part of serialization), > > > handle counts (I bumped the maximum handle count in that check), and > > > clearing map transitions (the map backpointer field needed a Smi > > > uninitialized value check). > > > > > > Original change's description: > > > > [serializer] Allocate during deserialization > > > > > > > > This patch removes the concept of reservations and a specialized > > > > deserializer allocator, and instead makes the deserializer allocate > > > > directly with the Heap's Allocate method. > > > > > > > > The major consequence of this is that the GC can now run during > > > > deserialization, which means that: > > > > > > > > a) Deserialized objects are visible to the GC, and > > > > b) Objects that the deserializer/deserialized objects point to can > > > > move. > > > > > > > > Point a) is mostly not a problem due to previous work in making > > > > deserialized objects "GC valid", i.e. making sure that they have a valid > > > > size before any subsequent allocation/safepoint. We now additionally > > > > have to initialize the allocated space with a valid tagged value -- this > > > > is a magic Smi value to keep "uninitialized" checks simple. > > > > > > > > Point b) is solved by Handlifying the deserializer. This involves > > > > changing any vectors of objects into vectors of Handles, and any object > > > > keyed map into an IdentityMap (we can't use Handles as keys because > > > > the object's address is no longer a stable hash). > > > > > > > > Back-references can no longer be direct chunk offsets, so instead the > > > > deserializer stores a Handle to each deserialized object, and the > > > > backreference is an index into this handle array. This encoding could > > > > be optimized in the future with e.g. a second pass over the serialized > > > > array which emits a different bytecode for objects that are and aren't > > > > back-referenced. > > > > > > > > Additionally, the slot-walk over objects to initialize them can no > > > > longer use absolute slot offsets, as again an object may move and its > > > > slot address would become invalid. Now, slots are walked as relative > > > > offsets to a Handle to the object, or as absolute slots for the case of > > > > root pointers. A concept of "slot accessor" is introduced to share the > > > > code between these two modes, and writing the slot (including write > > > > barriers) is abstracted into this accessor. > > > > > > > > Finally, the Code body walk is modified to deserialize all objects > > > > referred to by RelocInfos before doing the RelocInfo walk itself. This > > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate > > > > during a RelocInfo walk. > > > > > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > > > > size rather than byte size -- the size is expected to be tagged-aligned > > > > anyway, so now we get an extra few bits in the size encoding. > > > > > > > > Bug: chromium:1075999 > > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#70229} > > > > > > Bug: chromium:1075999 > > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828 > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#70267} > > > > Tbr: jgruber@chromium.org,ulan@chromium.org > > Bug: chromium:1075999 > > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991 > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70279} > > Tbr: jgruber@chromium.org,ulan@chromium.org > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng > Bug: chromium:1075999 > Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70288} TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org Bug: chromium:1075999, chromium:1135027 Change-Id: I5d0d9e49c0302d94ff7291834f5f18e7a0839eb7 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451030Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#70328}
-
- 02 Oct, 2020 3 commits
-
-
Leszek Swirski authored
This is a reland of c4a062a9 which was a reland of 28a30c57 which was a reland of 5d7a29c9 Fixes TSAN errors from non-atomic writes in the deserializer. Now all writes are (relaxed) atomic. Original change's description: > Reland^2 "[serializer] Allocate during deserialization" > > This is a reland of 28a30c57 > which was a reland of 5d7a29c9 > > The crashes were from calling RegisterDeserializerFinished on a null > Isolate pointer, for a deserializer that was never initialised > (specifically, ReadOnlyDeserializer when ROHeap is shared). > > Original change's description: > > Reland "[serializer] Allocate during deserialization" > > > > This is a reland of 5d7a29c9 > > > > This reland shuffles around the order of checks in Heap::AllocateRawWith > > to not check the new space addresses until it's known that this is a new > > space allocation. This fixes an UBSan failure during read-only space > > deserialization, which happens before the new space is initialized. > > > > It also fixes some issues discovered by --stress-snapshot, around > > serializing ThinStrings (which are now elided as part of serialization), > > handle counts (I bumped the maximum handle count in that check), and > > clearing map transitions (the map backpointer field needed a Smi > > uninitialized value check). > > > > Original change's description: > > > [serializer] Allocate during deserialization > > > > > > This patch removes the concept of reservations and a specialized > > > deserializer allocator, and instead makes the deserializer allocate > > > directly with the Heap's Allocate method. > > > > > > The major consequence of this is that the GC can now run during > > > deserialization, which means that: > > > > > > a) Deserialized objects are visible to the GC, and > > > b) Objects that the deserializer/deserialized objects point to can > > > move. > > > > > > Point a) is mostly not a problem due to previous work in making > > > deserialized objects "GC valid", i.e. making sure that they have a valid > > > size before any subsequent allocation/safepoint. We now additionally > > > have to initialize the allocated space with a valid tagged value -- this > > > is a magic Smi value to keep "uninitialized" checks simple. > > > > > > Point b) is solved by Handlifying the deserializer. This involves > > > changing any vectors of objects into vectors of Handles, and any object > > > keyed map into an IdentityMap (we can't use Handles as keys because > > > the object's address is no longer a stable hash). > > > > > > Back-references can no longer be direct chunk offsets, so instead the > > > deserializer stores a Handle to each deserialized object, and the > > > backreference is an index into this handle array. This encoding could > > > be optimized in the future with e.g. a second pass over the serialized > > > array which emits a different bytecode for objects that are and aren't > > > back-referenced. > > > > > > Additionally, the slot-walk over objects to initialize them can no > > > longer use absolute slot offsets, as again an object may move and its > > > slot address would become invalid. Now, slots are walked as relative > > > offsets to a Handle to the object, or as absolute slots for the case of > > > root pointers. A concept of "slot accessor" is introduced to share the > > > code between these two modes, and writing the slot (including write > > > barriers) is abstracted into this accessor. > > > > > > Finally, the Code body walk is modified to deserialize all objects > > > referred to by RelocInfos before doing the RelocInfo walk itself. This > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate > > > during a RelocInfo walk. > > > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > > > size rather than byte size -- the size is expected to be tagged-aligned > > > anyway, so now we get an extra few bits in the size encoding. > > > > > > Bug: chromium:1075999 > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#70229} > > > > Bug: chromium:1075999 > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70267} > > Tbr: jgruber@chromium.org,ulan@chromium.org > Bug: chromium:1075999 > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70279} Tbr: jgruber@chromium.org,ulan@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng Bug: chromium:1075999 Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#70288}
-
Clemens Backes authored
This reverts commit c4a062a9. Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33504 Original change's description: > Reland^2 "[serializer] Allocate during deserialization" > > This is a reland of 28a30c57 > which was a reland of 5d7a29c9 > > The crashes were from calling RegisterDeserializerFinished on a null > Isolate pointer, for a deserializer that was never initialised > (specifically, ReadOnlyDeserializer when ROHeap is shared). > > Original change's description: > > Reland "[serializer] Allocate during deserialization" > > > > This is a reland of 5d7a29c9 > > > > This reland shuffles around the order of checks in Heap::AllocateRawWith > > to not check the new space addresses until it's known that this is a new > > space allocation. This fixes an UBSan failure during read-only space > > deserialization, which happens before the new space is initialized. > > > > It also fixes some issues discovered by --stress-snapshot, around > > serializing ThinStrings (which are now elided as part of serialization), > > handle counts (I bumped the maximum handle count in that check), and > > clearing map transitions (the map backpointer field needed a Smi > > uninitialized value check). > > > > Original change's description: > > > [serializer] Allocate during deserialization > > > > > > This patch removes the concept of reservations and a specialized > > > deserializer allocator, and instead makes the deserializer allocate > > > directly with the Heap's Allocate method. > > > > > > The major consequence of this is that the GC can now run during > > > deserialization, which means that: > > > > > > a) Deserialized objects are visible to the GC, and > > > b) Objects that the deserializer/deserialized objects point to can > > > move. > > > > > > Point a) is mostly not a problem due to previous work in making > > > deserialized objects "GC valid", i.e. making sure that they have a valid > > > size before any subsequent allocation/safepoint. We now additionally > > > have to initialize the allocated space with a valid tagged value -- this > > > is a magic Smi value to keep "uninitialized" checks simple. > > > > > > Point b) is solved by Handlifying the deserializer. This involves > > > changing any vectors of objects into vectors of Handles, and any object > > > keyed map into an IdentityMap (we can't use Handles as keys because > > > the object's address is no longer a stable hash). > > > > > > Back-references can no longer be direct chunk offsets, so instead the > > > deserializer stores a Handle to each deserialized object, and the > > > backreference is an index into this handle array. This encoding could > > > be optimized in the future with e.g. a second pass over the serialized > > > array which emits a different bytecode for objects that are and aren't > > > back-referenced. > > > > > > Additionally, the slot-walk over objects to initialize them can no > > > longer use absolute slot offsets, as again an object may move and its > > > slot address would become invalid. Now, slots are walked as relative > > > offsets to a Handle to the object, or as absolute slots for the case of > > > root pointers. A concept of "slot accessor" is introduced to share the > > > code between these two modes, and writing the slot (including write > > > barriers) is abstracted into this accessor. > > > > > > Finally, the Code body walk is modified to deserialize all objects > > > referred to by RelocInfos before doing the RelocInfo walk itself. This > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate > > > during a RelocInfo walk. > > > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > > > size rather than byte size -- the size is expected to be tagged-aligned > > > anyway, so now we get an extra few bits in the size encoding. > > > > > > Bug: chromium:1075999 > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#70229} > > > > Bug: chromium:1075999 > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70267} > > Tbr: jgruber@chromium.org,ulan@chromium.org > Bug: chromium:1075999 > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70279} TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org Change-Id: Ib2f01db4cd9b55639d6a4af971bda865edb45e84 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1075999 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445250Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70280}
-
Leszek Swirski authored
This is a reland of 28a30c57 which was a reland of 5d7a29c9 The crashes were from calling RegisterDeserializerFinished on a null Isolate pointer, for a deserializer that was never initialised (specifically, ReadOnlyDeserializer when ROHeap is shared). Original change's description: > Reland "[serializer] Allocate during deserialization" > > This is a reland of 5d7a29c9 > > This reland shuffles around the order of checks in Heap::AllocateRawWith > to not check the new space addresses until it's known that this is a new > space allocation. This fixes an UBSan failure during read-only space > deserialization, which happens before the new space is initialized. > > It also fixes some issues discovered by --stress-snapshot, around > serializing ThinStrings (which are now elided as part of serialization), > handle counts (I bumped the maximum handle count in that check), and > clearing map transitions (the map backpointer field needed a Smi > uninitialized value check). > > Original change's description: > > [serializer] Allocate during deserialization > > > > This patch removes the concept of reservations and a specialized > > deserializer allocator, and instead makes the deserializer allocate > > directly with the Heap's Allocate method. > > > > The major consequence of this is that the GC can now run during > > deserialization, which means that: > > > > a) Deserialized objects are visible to the GC, and > > b) Objects that the deserializer/deserialized objects point to can > > move. > > > > Point a) is mostly not a problem due to previous work in making > > deserialized objects "GC valid", i.e. making sure that they have a valid > > size before any subsequent allocation/safepoint. We now additionally > > have to initialize the allocated space with a valid tagged value -- this > > is a magic Smi value to keep "uninitialized" checks simple. > > > > Point b) is solved by Handlifying the deserializer. This involves > > changing any vectors of objects into vectors of Handles, and any object > > keyed map into an IdentityMap (we can't use Handles as keys because > > the object's address is no longer a stable hash). > > > > Back-references can no longer be direct chunk offsets, so instead the > > deserializer stores a Handle to each deserialized object, and the > > backreference is an index into this handle array. This encoding could > > be optimized in the future with e.g. a second pass over the serialized > > array which emits a different bytecode for objects that are and aren't > > back-referenced. > > > > Additionally, the slot-walk over objects to initialize them can no > > longer use absolute slot offsets, as again an object may move and its > > slot address would become invalid. Now, slots are walked as relative > > offsets to a Handle to the object, or as absolute slots for the case of > > root pointers. A concept of "slot accessor" is introduced to share the > > code between these two modes, and writing the slot (including write > > barriers) is abstracted into this accessor. > > > > Finally, the Code body walk is modified to deserialize all objects > > referred to by RelocInfos before doing the RelocInfo walk itself. This > > is because RelocInfoIterator uses raw pointers, so we cannot allocate > > during a RelocInfo walk. > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > > size rather than byte size -- the size is expected to be tagged-aligned > > anyway, so now we get an extra few bits in the size encoding. > > > > Bug: chromium:1075999 > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70229} > > Bug: chromium:1075999 > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70267} Tbr: jgruber@chromium.org,ulan@chromium.org Bug: chromium:1075999 Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70279}
-
- 01 Oct, 2020 2 commits
-
-
Zhi An Ng authored
This reverts commit 28a30c57. Reason for revert: Broke Test262 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/38638? Original change's description: > Reland "[serializer] Allocate during deserialization" > > This is a reland of 5d7a29c9 > > This reland shuffles around the order of checks in Heap::AllocateRawWith > to not check the new space addresses until it's known that this is a new > space allocation. This fixes an UBSan failure during read-only space > deserialization, which happens before the new space is initialized. > > It also fixes some issues discovered by --stress-snapshot, around > serializing ThinStrings (which are now elided as part of serialization), > handle counts (I bumped the maximum handle count in that check), and > clearing map transitions (the map backpointer field needed a Smi > uninitialized value check). > > Original change's description: > > [serializer] Allocate during deserialization > > > > This patch removes the concept of reservations and a specialized > > deserializer allocator, and instead makes the deserializer allocate > > directly with the Heap's Allocate method. > > > > The major consequence of this is that the GC can now run during > > deserialization, which means that: > > > > a) Deserialized objects are visible to the GC, and > > b) Objects that the deserializer/deserialized objects point to can > > move. > > > > Point a) is mostly not a problem due to previous work in making > > deserialized objects "GC valid", i.e. making sure that they have a valid > > size before any subsequent allocation/safepoint. We now additionally > > have to initialize the allocated space with a valid tagged value -- this > > is a magic Smi value to keep "uninitialized" checks simple. > > > > Point b) is solved by Handlifying the deserializer. This involves > > changing any vectors of objects into vectors of Handles, and any object > > keyed map into an IdentityMap (we can't use Handles as keys because > > the object's address is no longer a stable hash). > > > > Back-references can no longer be direct chunk offsets, so instead the > > deserializer stores a Handle to each deserialized object, and the > > backreference is an index into this handle array. This encoding could > > be optimized in the future with e.g. a second pass over the serialized > > array which emits a different bytecode for objects that are and aren't > > back-referenced. > > > > Additionally, the slot-walk over objects to initialize them can no > > longer use absolute slot offsets, as again an object may move and its > > slot address would become invalid. Now, slots are walked as relative > > offsets to a Handle to the object, or as absolute slots for the case of > > root pointers. A concept of "slot accessor" is introduced to share the > > code between these two modes, and writing the slot (including write > > barriers) is abstracted into this accessor. > > > > Finally, the Code body walk is modified to deserialize all objects > > referred to by RelocInfos before doing the RelocInfo walk itself. This > > is because RelocInfoIterator uses raw pointers, so we cannot allocate > > during a RelocInfo walk. > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > > size rather than byte size -- the size is expected to be tagged-aligned > > anyway, so now we get an extra few bits in the size encoding. > > > > Bug: chromium:1075999 > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70229} > > Bug: chromium:1075999 > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70267} TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org Change-Id: Ieed68332ef6a7ad36db061e3f48be0f28673d7a2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1075999 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441608Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70268}
-
Leszek Swirski authored
This is a reland of 5d7a29c9 This reland shuffles around the order of checks in Heap::AllocateRawWith to not check the new space addresses until it's known that this is a new space allocation. This fixes an UBSan failure during read-only space deserialization, which happens before the new space is initialized. It also fixes some issues discovered by --stress-snapshot, around serializing ThinStrings (which are now elided as part of serialization), handle counts (I bumped the maximum handle count in that check), and clearing map transitions (the map backpointer field needed a Smi uninitialized value check). Original change's description: > [serializer] Allocate during deserialization > > This patch removes the concept of reservations and a specialized > deserializer allocator, and instead makes the deserializer allocate > directly with the Heap's Allocate method. > > The major consequence of this is that the GC can now run during > deserialization, which means that: > > a) Deserialized objects are visible to the GC, and > b) Objects that the deserializer/deserialized objects point to can > move. > > Point a) is mostly not a problem due to previous work in making > deserialized objects "GC valid", i.e. making sure that they have a valid > size before any subsequent allocation/safepoint. We now additionally > have to initialize the allocated space with a valid tagged value -- this > is a magic Smi value to keep "uninitialized" checks simple. > > Point b) is solved by Handlifying the deserializer. This involves > changing any vectors of objects into vectors of Handles, and any object > keyed map into an IdentityMap (we can't use Handles as keys because > the object's address is no longer a stable hash). > > Back-references can no longer be direct chunk offsets, so instead the > deserializer stores a Handle to each deserialized object, and the > backreference is an index into this handle array. This encoding could > be optimized in the future with e.g. a second pass over the serialized > array which emits a different bytecode for objects that are and aren't > back-referenced. > > Additionally, the slot-walk over objects to initialize them can no > longer use absolute slot offsets, as again an object may move and its > slot address would become invalid. Now, slots are walked as relative > offsets to a Handle to the object, or as absolute slots for the case of > root pointers. A concept of "slot accessor" is introduced to share the > code between these two modes, and writing the slot (including write > barriers) is abstracted into this accessor. > > Finally, the Code body walk is modified to deserialize all objects > referred to by RelocInfos before doing the RelocInfo walk itself. This > is because RelocInfoIterator uses raw pointers, so we cannot allocate > during a RelocInfo walk. > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > size rather than byte size -- the size is expected to be tagged-aligned > anyway, so now we get an extra few bits in the size encoding. > > Bug: chromium:1075999 > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70229} Bug: chromium:1075999 Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70267}
-
- 30 Sep, 2020 2 commits
-
-
Leszek Swirski authored
This reverts commit 5d7a29c9. Reason for revert: UBSan -- https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/13100 Original change's description: > [serializer] Allocate during deserialization > > This patch removes the concept of reservations and a specialized > deserializer allocator, and instead makes the deserializer allocate > directly with the Heap's Allocate method. > > The major consequence of this is that the GC can now run during > deserialization, which means that: > > a) Deserialized objects are visible to the GC, and > b) Objects that the deserializer/deserialized objects point to can > move. > > Point a) is mostly not a problem due to previous work in making > deserialized objects "GC valid", i.e. making sure that they have a valid > size before any subsequent allocation/safepoint. We now additionally > have to initialize the allocated space with a valid tagged value -- this > is a magic Smi value to keep "uninitialized" checks simple. > > Point b) is solved by Handlifying the deserializer. This involves > changing any vectors of objects into vectors of Handles, and any object > keyed map into an IdentityMap (we can't use Handles as keys because > the object's address is no longer a stable hash). > > Back-references can no longer be direct chunk offsets, so instead the > deserializer stores a Handle to each deserialized object, and the > backreference is an index into this handle array. This encoding could > be optimized in the future with e.g. a second pass over the serialized > array which emits a different bytecode for objects that are and aren't > back-referenced. > > Additionally, the slot-walk over objects to initialize them can no > longer use absolute slot offsets, as again an object may move and its > slot address would become invalid. Now, slots are walked as relative > offsets to a Handle to the object, or as absolute slots for the case of > root pointers. A concept of "slot accessor" is introduced to share the > code between these two modes, and writing the slot (including write > barriers) is abstracted into this accessor. > > Finally, the Code body walk is modified to deserialize all objects > referred to by RelocInfos before doing the RelocInfo walk itself. This > is because RelocInfoIterator uses raw pointers, so we cannot allocate > during a RelocInfo walk. > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > size rather than byte size -- the size is expected to be tagged-aligned > anyway, so now we get an extra few bits in the size encoding. > > Bug: chromium:1075999 > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70229} TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org Change-Id: I2bd792a24861e8f54897e51522769b50f8f814e2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1075999 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440827 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70231}
-
Leszek Swirski authored
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}
-
- 28 Apr, 2020 3 commits
-
-
Jakob Gruber authored
This is a reland of ad5b005e Original change's description: > [snapshot] Expose the serializer through %SerializeDeserializeNow > > ... in order to exercise the snapshot/ component from mjsunit tests > and fuzzers. > > * Since the serializer and deserializer can now be called at any time > instead of only in a tightly controlled environment, several > assumptions (such as an empty execution stack, no microtasks, no > handles) no longer hold and had to be made configurable through > SerializerFlags. > > * Root iteration now skips more root categories which were previously > guaranteed to be empty (e.g. the stack, microtask queue, handles). > > * The %SerializeDeserializeNow runtime function triggers > serialization, deserialization, and heap verification on the current > isolate and native context. > > Support is not yet complete and will be extended in future work. Once > all mjsunit tests successfully run, we can add a new test mode to > stress serialization. > > Bug: v8:10416 > Change-Id: Ie7ff441a761257dd7f256d0a33e73227850074ac > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159495 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67423} Tbr: delphick@chromium.org,ulan@chromium.org Bug: v8:10416 Change-Id: Ibed04c0f0b72fabcf811d8b18a1479391a11568b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170090Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67426}
-
Nico Hartmann authored
This reverts commit ad5b005e. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/36070? Original change's description: > [snapshot] Expose the serializer through %SerializeDeserializeNow > > ... in order to exercise the snapshot/ component from mjsunit tests > and fuzzers. > > * Since the serializer and deserializer can now be called at any time > instead of only in a tightly controlled environment, several > assumptions (such as an empty execution stack, no microtasks, no > handles) no longer hold and had to be made configurable through > SerializerFlags. > > * Root iteration now skips more root categories which were previously > guaranteed to be empty (e.g. the stack, microtask queue, handles). > > * The %SerializeDeserializeNow runtime function triggers > serialization, deserialization, and heap verification on the current > isolate and native context. > > Support is not yet complete and will be extended in future work. Once > all mjsunit tests successfully run, we can add a new test mode to > stress serialization. > > Bug: v8:10416 > Change-Id: Ie7ff441a761257dd7f256d0a33e73227850074ac > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159495 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67423} TBR=ulan@chromium.org,jgruber@chromium.org,delphick@chromium.org Change-Id: Ie30b94c9ec6e4463bed6cc87dd6525f469fdf84a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10416 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170089Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#67424}
-
Jakob Gruber authored
... in order to exercise the snapshot/ component from mjsunit tests and fuzzers. * Since the serializer and deserializer can now be called at any time instead of only in a tightly controlled environment, several assumptions (such as an empty execution stack, no microtasks, no handles) no longer hold and had to be made configurable through SerializerFlags. * Root iteration now skips more root categories which were previously guaranteed to be empty (e.g. the stack, microtask queue, handles). * The %SerializeDeserializeNow runtime function triggers serialization, deserialization, and heap verification on the current isolate and native context. Support is not yet complete and will be extended in future work. Once all mjsunit tests successfully run, we can add a new test mode to stress serialization. Bug: v8:10416 Change-Id: Ie7ff441a761257dd7f256d0a33e73227850074ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159495 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#67423}
-
- 02 May, 2019 1 commit
-
-
Maciej Goszczycki authored
Code relocation info is now always allocated in old-space. Before relocation info allocated for placeholders and builtins (which get replaced with trampolines in nosnap builds) would become unreachable. Since read-only space is not GCed and ReadOnlyHeapIterator doesn't check for reachability, ValidateSnapshot would fail finding unreachable objects returned by ReadOnlyHeapIterator. Because trampoline relocation info gets replaced with canonical one, this only affects no-embdded-builtins nosnap builds, which don't get much benefit from read-only relocation info anyway. A new check has been added to the read-only deserializer to verify that every read-only object is reachable at mksnapshot-time. The CombinedHeapIterator iteration order was changed to iterate over read-only space first, because that's how HeapIterator worked. This is a reland of 3d1d8eae Original change's description: > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator. > > Read-only space sharing requires an iterator independent of heap. This > also enables future removal of read-only space from heap. > > Bug: v8:7464 > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 > Commit-Queue: Maciej Goszczycki <goszczycki@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60819} Bug: v8:7464 Change-Id: I49ae070955b77956962334a84f762ab29052d5ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#61185}
-
- 27 Mar, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: Ia789e21ac9324fca77f559a88180fadd97491a91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541050 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#60486}
-
- 08 Feb, 2019 3 commits
-
-
Igor Sheludko authored
... as it's no longer needed. Bug: v8:8794, v8:8562 Change-Id: Ia5149bab33af219e5cdc6909af4688e53f1409fa Reviewed-on: https://chromium-review.googlesource.com/c/1460458 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#59463}
-
Igor Sheludko authored
... as it's no longer needed. Bug: v8:8794, v8:8562 Change-Id: Ifbc4f5f5d34f24ff4ba8f32309e8a032268c12c0 Reviewed-on: https://chromium-review.googlesource.com/c/1460457 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#59461}
-
Igor Sheludko authored
... as they are no longer needed. Bug: v8:8794, v8:8562 Change-Id: Ib5d87fce9834839410b0dffce95b4a8ae4f946cc Reviewed-on: https://chromium-review.googlesource.com/c/1460456Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#59457}
-
- 20 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Merging the temporary HeapObjectPtr back into HeapObject. Bug: v8:3770 Change-Id: I5bcd23ca2f5ba862cf5b52955dca143e531c637b Reviewed-on: https://chromium-review.googlesource.com/c/1386492 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58410}
-
- 16 Oct, 2018 1 commit
-
-
Dan Elphick authored
In preparation for sharing RO_SPACE between all Isolates within a process, this first pulls RO_SPACE out of the Startup snapshot and puts it in its own ReadOnly snapshot. The snapshot is first populated with the read-only roots. After that the StartupSerializer serializes as before but starting from the first mutable root. References to objects in the ReadOnly snapshot that aren't themselves roots are added to a new cache called ReadOnlyObjectCache which functions like the PartialSnapshotCache but lives in the ReadOnlySerializer rather than the StartupSerializer. These cache entries are referenced using a new bytecode: ReadOnlyObjectCache. (To make room for this, the ApiReference bytecode has been moved). To reduce code duplication, the StartupSerializer has been refactored to create a new base class RootSerializer, which ReadOnlySerializer also subclasses. The base class is responsible primarily for keeping track of already serialized roots and visiting the roots. Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iff26042886130ae22eccf2e11b35f6f226f4a792 Bug: v8:8191 Reviewed-on: https://chromium-review.googlesource.com/c/1244676 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56681}
-