- 05 Apr, 2022 1 commit
-
-
Camillo Bruni authored
Bug: v8:11263 Change-Id: I6f9f43125e5a1b27d8f8595bbbebdff2665968da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3471635Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#79771}
-
- 26 Oct, 2021 1 commit
-
-
Leszek Swirski authored
Add a SerializedCodeData constructor which skips all sanity checks aside from the source hash check, to be used after off-thread deserialization (which does these other checks already). In particular, this skips doing the checksum again, which would otherwise require a second walk over the serialized data. This requires saving the off-thread sanity check result (in the case of a failure), since it is no longer recomputed. Change-Id: I664c309c9cb8dca94a74b4293c84ceb353f37ed4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3240402 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77537}
-
- 24 Aug, 2021 2 commits
-
-
Maya Lekova authored
This reverts commit 26609973. Reason for revert: Breaks code_serializer tests - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/36427/overview Original change's description: > [codegen] Assert that deserialized SFIs have correct origins > > Re-use the same check we already have in place for the > compilation cache for when we use CodeSerializer::Deserialize. > > - Move HasOrigin to SharedFunctionInfo::HasMatchingOrigin > - HasMatchingOrigin no longer allocates > - Pass ScriptDetails in more places > > Bug: v8:10284 > Change-Id: I6e074bd1e7db9a35fdf7123d04a65841d9813e02 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090968 > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76451} Bug: v8:10284 Change-Id: I234fcf031001819b05dbcdd421f235f71e9805b2 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114143 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#76456}
-
Camillo Bruni authored
Re-use the same check we already have in place for the compilation cache for when we use CodeSerializer::Deserialize. - Move HasOrigin to SharedFunctionInfo::HasMatchingOrigin - HasMatchingOrigin no longer allocates - Pass ScriptDetails in more places Bug: v8:10284 Change-Id: I6e074bd1e7db9a35fdf7123d04a65841d9813e02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090968 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76451}
-
- 09 Aug, 2021 1 commit
-
-
Leszek Swirski authored
To consume a code cache off-thread 1. The embedder creates a CachedData object wrapping the data blob. 2. The embedder calls ScriptCompiler::StartConsumingCodeCache with the CachedData, and receives a ScriptCompiler::CodeCacheConsumeTask which takes ownership of the CachedData. 3. The embedder calls ScriptCompiler::CodeCacheConsumeTask::Run on a different thread. 4. Once this completes, the embedded passes the completed task as an optional argument into Source constructor, and calls Compile as before. This is roughly similar to how streaming compilation works, with the QoL improvement that Source owns the CodeCacheConsumeTask and therefore we can reuse the same Compile method and do the off-thread finalization behind the scenes inside Compile. On the v8::internal side, ScriptCompiler::CodeCacheConsumeTask wraps a v8::internal::BackgroundDeserializeTask, which has a Run and a Finish method. The Run creates a LocalIsolate (again, similar to BackgroundCompileTask), calls some helpers on CodeSerializer, and stores the pre-finalization result in a OffThreadDeserializeData structure. This stores Persistent Handles to the off-thread initialized SFI and a vector of Scripts needing fixing up, and it owns the PersistentHandles object which owns those Handles. Finally, the Finish method consumes this OffThreadDeserializeData structure, fixes up Scripts, moves the SFI Handle into the caller HandleScope, and that's it. Since we don't yet have the source at off-thread deserialization time, the various code cache sanity checks are done without the source hash when deserializing, and the Finish method re-does them now that the source is available. Bug: chromium:1075999 Change-Id: If1faf35ba3ef840fa4e735581d0b29c96c1d5fc8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067322 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#76155}
-
- 18 Jun, 2021 1 commit
-
-
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 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}
-
- 06 May, 2020 1 commit
-
-
Leszek Swirski authored
The Isolate* parameter in the deserializer SanityCheck is unused, and is blocking the use of the deserializer off-thread. Bug: chromium:1075999 Change-Id: I0f2acae3c1aff62aafeb2680a2eecb44b1608803 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184290 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67594}
-
- 25 Nov, 2019 1 commit
-
-
Sam Maier authored
adler32 is strictly faster than the old checksum - see this doc: https://docs.google.com/document/d/1fFhuShavlUwf0FqTc-6L3XLYbAVe0DhpmHSv4oenZL8/edit?pli=1#heading=h.ojvfq6akbz5f adler32 also no longer requires alignment to be maintained. Bug: chromium:833361 Change-Id: I3dbfa699b712aa908c87e6f8261756a4a1209df4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925562 Commit-Queue: Sam Maier <smaier@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65160}
-
- 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}
-
- 14 Feb, 2019 1 commit
-
-
Yang Guo authored
R=leszeks@chromium.org Change-Id: Ib66b36884be7dd1283eb0375cfaf94a5b503f162 Reviewed-on: https://chromium-review.googlesource.com/c/1470110Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#59594}
-
- 13 Feb, 2019 1 commit
-
-
Nico Weber authored
For macros expanding to function definitions, I removed the spurious ; after macro invocations. For macros expandign to function declarations, I made the ; required and consistently inserted it. No behavior change. Bug: chromium:926235 Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549 Reviewed-on: https://chromium-review.googlesource.com/c/1467545Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59558}
-
- 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}
-
- 26 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Tbr: ahaas@chromium.org,leszeks@chromium.org,verwaest@chromium.org Bug: v8:3770 Change-Id: Ia6530fbb70dac05e9972283781c3550d8b50e1eb Reviewed-on: https://chromium-review.googlesource.com/c/1390116 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58470}
-
- 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}
-
- 11 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This: - documents removal of Code's stub key field. - removes SerializedCodeData's CodeStubKeys field. - removes masm's custom self-reference marker mechanism. Bug: v8:7777 Change-Id: Ie5c51bc895e508acdeb3994cf5558a2cf4c21540 Reviewed-on: https://chromium-review.googlesource.com/c/1367744 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58145}
-
- 07 Dec, 2018 3 commits
-
-
Jakob Gruber authored
This is a reland of f849396c Original change's description: > [nojit] Remove code stubs > > All stubs have been migrated to builtins. This CL removes most related > code. > > Bug: v8:7777, v8:5784 > Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad > Reviewed-on: https://chromium-review.googlesource.com/c/1365284 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58093} Tbr: mstarzinger@chromium.org,yangguo@chromium.org,jkummerow@chromium.org,bmeurer@chromium.org Bug: v8:7777, v8:5784 Change-Id: I005ee2a820d49a75a90481d262a310e4ccfd1391 Reviewed-on: https://chromium-review.googlesource.com/c/1367746Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58101}
-
Jakob Gruber authored
This reverts commit f849396c. Reason for revert: arm64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/24229 Original change's description: > [nojit] Remove code stubs > > All stubs have been migrated to builtins. This CL removes most related > code. > > Bug: v8:7777, v8:5784 > Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad > Reviewed-on: https://chromium-review.googlesource.com/c/1365284 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58093} TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,bmeurer@chromium.org Change-Id: I52c3abd3f4e5872fe26ed7e527a58b118e02b387 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7777, v8:5784 Reviewed-on: https://chromium-review.googlesource.com/c/1367804Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58095}
-
Jakob Gruber authored
All stubs have been migrated to builtins. This CL removes most related code. Bug: v8:7777, v8:5784 Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad Reviewed-on: https://chromium-review.googlesource.com/c/1365284 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58093}
-
- 20 Nov, 2018 1 commit
-
-
Yang Guo authored
R=jgruber@chromium.org Change-Id: I07d9c2f952f0ca3cf50f5faa4ad8db78be2a5b04 Reviewed-on: https://chromium-review.googlesource.com/c/1342926Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57642}
-
- 12 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I413ce57f7fa91cef2445995ca22650477f92b0df Reviewed-on: https://chromium-review.googlesource.com/c/1321892Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57445}
-
- 31 Oct, 2018 1 commit
-
-
Jakob Gruber authored
Now that lazy deserialization has been removed, we can roll back all the mechanisms we introduced to support lazy single-builtin deserialization. This CL moves serialized builtin code objects (i.e. off-heap-trampolines in most cases) back into the startup snapshot. Support classes for builtin serialization and deserialization, as well as the builtins snapshot itself are removed. Templatization on the allocator class is removed as well. Tbr: delphick@chromium.org Bug: v8:6666, v8:7990 Change-Id: I2a910f8d3278b7e27b5f18ad408361ebd18871cc Reviewed-on: https://chromium-review.googlesource.com/c/1304539Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57160}
-
- 16 Oct, 2018 1 commit
-
-
Florian Sattler authored
Change-Id: Ic8fe43e65fddec16b3c5c029acebda5ba1805e08 Reviewed-on: https://chromium-review.googlesource.com/c/1275812Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Florian Sattler <sattlerf@google.com> Cr-Commit-Position: refs/heads/master@{#56671}
-
- 25 Sep, 2018 3 commits
-
-
Yang Guo authored
This is a reland of bcb8d49b TBR=petermarshall@chromium.org Original change's description: > [snapshot] add checksum to startup snapshot > > We already had checksumming for code cache data. We now extend > checksumming to the startup snapshot to catch data corruption early. > > The performance impact for deserialization is a regression of 1-2%, > which should be acceptable. > > Sample output for the included test with --profile-deserialization: > > [Verifying snapshot checksum took 0.023 ms] > [Deserializing isolate (134348 bytes) took 1.891 ms] > [Verifying snapshot checksum took 0.024 ms] > [Deserializing isolate (134348 bytes) took 1.654 ms] > [Deserializing context #0 (47208 bytes) took 0.331 ms] > Deserialization will reserve: > 208168 bytes per isolate > 123368 bytes per context #0 > Snapshot blob consists of: > 134492 bytes in 6 chunks for startup > 115272 bytes for builtins > 47152 bytes in 31 chunks for context #0 > [Verifying snapshot checksum took 0.048 ms] > [Verifying snapshot checksum took 0.043 ms] > > R=peria@chromium.org, petermarshall@chromium.org > > Bug: chromium:881417 > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng > Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7 > Reviewed-on: https://chromium-review.googlesource.com/1241874 > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56217} Bug: chromium:881417 Change-Id: I037f378fc2d45c3e0fa670bf538df68cbba5c53c Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1243191Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56224}
-
Clemens Hammacher authored
This reverts commit bcb8d49b. Reason for revert: MSan compile error: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/23025 Original change's description: > [snapshot] add checksum to startup snapshot > > We already had checksumming for code cache data. We now extend > checksumming to the startup snapshot to catch data corruption early. > > The performance impact for deserialization is a regression of 1-2%, > which should be acceptable. > > Sample output for the included test with --profile-deserialization: > > [Verifying snapshot checksum took 0.023 ms] > [Deserializing isolate (134348 bytes) took 1.891 ms] > [Verifying snapshot checksum took 0.024 ms] > [Deserializing isolate (134348 bytes) took 1.654 ms] > [Deserializing context #0 (47208 bytes) took 0.331 ms] > Deserialization will reserve: > 208168 bytes per isolate > 123368 bytes per context #0 > Snapshot blob consists of: > 134492 bytes in 6 chunks for startup > 115272 bytes for builtins > 47152 bytes in 31 chunks for context #0 > [Verifying snapshot checksum took 0.048 ms] > [Verifying snapshot checksum took 0.043 ms] > > R=peria@chromium.org, petermarshall@chromium.org > > Bug: chromium:881417 > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng > Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7 > Reviewed-on: https://chromium-review.googlesource.com/1241874 > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56217} TBR=peria@chromium.org,yangguo@chromium.org,petermarshall@chromium.org Change-Id: Iccb82092858ab68a5d6ae9552fa716108eda354b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:881417 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1243190Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56221}
-
Yang Guo authored
We already had checksumming for code cache data. We now extend checksumming to the startup snapshot to catch data corruption early. The performance impact for deserialization is a regression of 1-2%, which should be acceptable. Sample output for the included test with --profile-deserialization: [Verifying snapshot checksum took 0.023 ms] [Deserializing isolate (134348 bytes) took 1.891 ms] [Verifying snapshot checksum took 0.024 ms] [Deserializing isolate (134348 bytes) took 1.654 ms] [Deserializing context #0 (47208 bytes) took 0.331 ms] Deserialization will reserve: 208168 bytes per isolate 123368 bytes per context #0 Snapshot blob consists of: 134492 bytes in 6 chunks for startup 115272 bytes for builtins 47152 bytes in 31 chunks for context #0 [Verifying snapshot checksum took 0.048 ms] [Verifying snapshot checksum took 0.043 ms] R=peria@chromium.org, petermarshall@chromium.org Bug: chromium:881417 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7 Reviewed-on: https://chromium-review.googlesource.com/1241874Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56217}
-
- 22 Aug, 2018 1 commit
-
-
Ross McIlroy authored
TBR=yangguo@chromium.org Change-Id: Iadeb5828daf4db341c58534ff2b23141f241dfb9 Reviewed-on: https://chromium-review.googlesource.com/1184841 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#55314}
-
- 04 Jul, 2018 1 commit
-
-
Yang Guo authored
Bug: v8:7887 Change-Id: I3904981f06efcb1fb83e863d0be6a16ebaaf17f2 Reviewed-on: https://chromium-review.googlesource.com/1113930Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#54189}
-