- 08 Mar, 2021 1 commit
-
-
Santiago Aboy Solanes authored
If a method happens on the main thread and only on the main thread (i.e. it will never be run on the background), it is safer to use non-atomic accessors as TSAN will give warnings if we use them improperly. As a drive-by, pass the isolate as a parameter where it was readily available as it saves us from getting the isolate from the object later on. Bug: v8:7790 Change-Id: Id9bdd69254edc60b0331a32fccf1479a95b7d286 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732669Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#73251}
-
- 19 Feb, 2021 1 commit
-
-
Mike Stanton authored
Code objects are exposed through JSFunction and SharedFunctionInfo. If they are builtins, we don't have to worry about background threads seeing partially initialized code objects. If they are optimized code objects, we may. Background threads read the code fields with AcquireLoad semantics. The fields are set on the main thread with ReleaseStore semantics when appropriate. Special care is taken when setting an optimized code object in a closure in the interpreter entry stub. Since the MacroAssembler doesn't support ReleaseStore semantics, this CL ensures that the optimized code object is stored with those semantics in the feedback vector, where the interpreter entry stub finds it. Bug: v8:7790 Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72869}
-
- 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}
-
- 16 Nov, 2020 1 commit
-
-
Igor Sheludko authored
... and use Name::hash() where the hash is expected to be computed. In particular, when we are dealing with internalized strings or symbols. Bug: v8:11074 Change-Id: Ida22f134fee0ddf2c9b962d1bcca6aa0b632af5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529451Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71200}
-
- 16 Oct, 2020 1 commit
-
-
Igor Sheludko authored
... and add respective regression tests. This CL also adds similar regression tests for TransitionArray but it doesn't have the same issue as DescriptorArray. Bug: chromium:1133527 Change-Id: I668a90f126d76af0a39816ce8697cb29bc65d01b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465833Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70570}
-
- 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 2 commits
-
-
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}
-
Santiago Aboy Solanes authored
We can use tag dispatching to distinguish between the synchronized and non-synchronized accessors. Also eliminated the need of adding explicit "synchronized" in the name when using the macros. As a note, we currently have one case of using both relaxed and synchronized accessors (Map::instance_descriptors). Cleaned up: * BytecodeArray::source_position_table * Code::code_data_container * Code::source_position_table * FunctionTemplateInfo::call_code * Map::instance_descriptors * Map::layout_descriptor * SharedFunctionInfo::function_data Bug: v8:7790 Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70306}
-
- 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}
-
- 27 Jul, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I9e62a60911d69aec20a59e92f989208f8eac6cb5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243219Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69065}
-
- 01 Jul, 2020 1 commit
-
-
Santiago Aboy Solanes authored
What we need is a multiple readers single writer (MRSW) lock. The main thread is the only one that is going to be writing, while the readers might be either the main thread or background threads. The shared_mutex is in the isolate itself, so that different isolates will not block each other. Bug: v8:7790 Change-Id: Idd6bb1826bd0cc6279df1c0694a84e00d53a7eae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241513 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68639}
-
- 11 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
This is for consistency and compiler-enforced type safety. No change in behavior intended. Change-Id: I31467832ba6c63fd5f97df9fee6221559b283d67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852766 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64244}
-
- 09 Jul, 2019 1 commit
-
-
Igor Sheludko authored
Tbr: verwaest@chromium.org Bug: v8:9353 Change-Id: I8164e2235ca43e203410277b86e6f166010c11d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687673Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62597}
-
- 03 Jul, 2019 1 commit
-
-
Igor Sheludko authored
... and DescriptorArray. Bug: v8:9353 Change-Id: Ie05cbdc57f95e2edadbbed47cc2252bd381a76c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683727Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62499}
-
- 23 May, 2019 1 commit
-
-
Clemens Hammacher authored
This CL was generated by an automatic clang AST rewriter using this matcher expression: callExpr( callee( cxxMethodDecl( hasName("operator->"), ofClass(isSameOrDerivedFrom("v8::internal::Object")) ) ), argumentCountIs(1) ) The "->" at the expression location was then rewritten to ".". R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org Bug: v8:9183, v8:3770 No-Try: true No-Tree-Checks: true Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61764}
-
- 20 May, 2019 1 commit
-
-
Yang Guo authored
Code that is being moved primarily deal with layout of a JSObject, accessing properties and elements, and map transitions. NOTREECHECKS=true NOTRY=true Bug: v8:9247 Change-Id: Ibce5d5926ac4021c8d40c4dd109948775ce1da58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613994 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61638}
-
- 06 May, 2019 1 commit
-
-
Toon Verwaest authored
This is a reland of b0c4a876 Original change's description: > [json] Speed up json parsing > > - scan using raw data pointers + GC callback > - scan using scanner tables > - cap internalizing large string values > - inline fast transitioning logic > > Fixes previous CL by moving AllowHeapAllocation to callers of > ReportUnexpectedCharacter where needed to make it clear we need to exit. > > Tbr: ulan@chromium.org > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61159} Change-Id: I0d713e02d243723df2d2a7c252eae44a6648b6b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596444Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61247}
-
- 03 May, 2019 1 commit
-
-
Sigurd Schneider authored
This reverts commit bbd740f0. Reason for revert: blocks lkgr due to layout test failure: https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/31607 Original change's description: > Reland "[json] Speed up json parsing" > > This is a reland of b0c4a876 > > Original change's description: > > [json] Speed up json parsing > > > > - scan using raw data pointers + GC callback > > - scan using scanner tables > > - cap internalizing large string values > > - inline fast transitioning logic > > > > Fixes previous CL by moving AllowHeapAllocation to callers of > > ReportUnexpectedCharacter where needed to make it clear we need to exit. > > > > Tbr: ulan@chromium.org > > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778 > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#61159} > > Tbr: verwaest@chromium.org > Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel > Change-Id: Ic7d0057178c649fc45b8c8f4587ee9128e351515 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593292 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61179} TBR=ulan@chromium.org,ishell@google.com,verwaest@google.com,ishell@chromium.org,verwaest@chromium.org Change-Id: I3ae8f9ce8214bebe7fab9d87c5daf8cdfdb94199 No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594438 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61194}
-
- 02 May, 2019 3 commits
-
-
Toon Verwaest authored
This is a reland of b0c4a876 Original change's description: > [json] Speed up json parsing > > - scan using raw data pointers + GC callback > - scan using scanner tables > - cap internalizing large string values > - inline fast transitioning logic > > Fixes previous CL by moving AllowHeapAllocation to callers of > ReportUnexpectedCharacter where needed to make it clear we need to exit. > > Tbr: ulan@chromium.org > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61159} Tbr: verwaest@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel Change-Id: Ic7d0057178c649fc45b8c8f4587ee9128e351515 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593292 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#61179}
-
Michael Achenbach authored
This reverts commit b0c4a876. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/26470 Original change's description: > [json] Speed up json parsing > > - scan using raw data pointers + GC callback > - scan using scanner tables > - cap internalizing large string values > - inline fast transitioning logic > > Fixes previous CL by moving AllowHeapAllocation to callers of > ReportUnexpectedCharacter where needed to make it clear we need to exit. > > Tbr: ulan@chromium.org > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61159} TBR=ulan@chromium.org,ishell@google.com,ishell@chromium.org,verwaest@chromium.org Change-Id: Ibe823e187d9ab999be7278140b0ed31868440e9e No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593090Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#61163}
-
Toon Verwaest authored
- scan using raw data pointers + GC callback - scan using scanner tables - cap internalizing large string values - inline fast transitioning logic Fixes previous CL by moving AllowHeapAllocation to callers of ReportUnexpectedCharacter where needed to make it clear we need to exit. Tbr: ulan@chromium.org Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61159}
-
- 30 Apr, 2019 4 commits
-
-
Sathya Gunasekaran authored
This reverts commit 36dd2bca. Reason for revert: msan still failing https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/26453 Original change's description: > Reland "[json] Speed up json parsing" > > This is a reland of de8aaef5 > > Original change's description: > > [json] Speed up json parsing > > > > - scan using raw data pointers + GC callback > > - scan using scanner tables > > - cap internalizing large string values > > - inline fast transitioning logic > > > > Change-Id: I545620017b38b80e4193dfaf19381411adf5ff89 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584320 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#61132} > > Tbr: ulan@chromium.org > Change-Id: Iafd5e7c750a9f3eae706baf51dc4c9237c916132 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588887 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61136} TBR=ulan@chromium.org,gsathya@chromium.org,ishell@chromium.org,verwaest@chromium.org Change-Id: If0a34e017fed7688873c21f4b65f62b246820732 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1590626Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61137}
-
Toon Verwaest authored
This is a reland of de8aaef5 Original change's description: > [json] Speed up json parsing > > - scan using raw data pointers + GC callback > - scan using scanner tables > - cap internalizing large string values > - inline fast transitioning logic > > Change-Id: I545620017b38b80e4193dfaf19381411adf5ff89 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584320 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61132} Tbr: ulan@chromium.org Change-Id: Iafd5e7c750a9f3eae706baf51dc4c9237c916132 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588887 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61136}
-
Sathya Gunasekaran authored
This reverts commit de8aaef5. Reason for revert: breaks MSAN https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8914730548828313776/+/steps/Check/0/logs/json/0 Original change's description: > [json] Speed up json parsing > > - scan using raw data pointers + GC callback > - scan using scanner tables > - cap internalizing large string values > - inline fast transitioning logic > > Change-Id: I545620017b38b80e4193dfaf19381411adf5ff89 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584320 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61132} TBR=ulan@chromium.org,ishell@chromium.org,verwaest@chromium.org Change-Id: I870c82f6f2a5bc3d2dfea57d5d6306cdccbbe935 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1590384Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61134}
-
Toon Verwaest authored
- scan using raw data pointers + GC callback - scan using scanner tables - cap internalizing large string values - inline fast transitioning logic Change-Id: I545620017b38b80e4193dfaf19381411adf5ff89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584320 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#61132}
-
- 09 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The incremental migration required several pairs of functionally equivalent macros. This patch consolidates everything onto the respective new version and drops the obsolete versions. Bug: v8:3770 Change-Id: I4fb05ff223e8250c83a13f46840810b0893f410b Reviewed-on: https://chromium-review.googlesource.com/c/1398223Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58659}
-
- 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}
-
- 29 Nov, 2018 2 commits
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: If41076a377d12922cc3df859c678e1f20b99b00d Reviewed-on: https://chromium-review.googlesource.com/c/1351242 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57923}
-
Jakob Kummerow authored
TransitionArray, NormalizedMapCache, DependentCode to the new design. Bug: v8:3770 Change-Id: I8bd56f231fb62b146e0fb05989418aedb62a628b Reviewed-on: https://chromium-review.googlesource.com/c/1350287 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#57921}
-
- 27 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I4da6404aa968adca1fbb49029fc304622101d6c3 Reviewed-on: https://chromium-review.googlesource.com/c/1349112 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57853}
-
- 22 Nov, 2018 1 commit
-
-
Shiyu Zhang authored
This is a reland of 6ec90ece Original change's description: > Reland "Create a fast path to get migration target when updating map" > > This is a reland of c285380c > > Original change's description: > > Create a fast path to get migration target when updating map > > > > During map updating, store the pointer to new map in the > > raw_transitions slot of the old map that is deprecated from map > > transition tree. Thus, we can get the migration target directly > > instead of TryReplayPropertyTransitions when updating map. > > > > This can improve Speedometer2.0 Elm-TodoMVC case by ~5% on ATOM > > Chromebook and ~9% on big-core Ubuntu. > > > > Change-Id: I56f9ce5183bbdd567b964890f623ef0ceed9b7db > > Reviewed-on: https://chromium-review.googlesource.com/1233433 > > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#56303} > > Change-Id: Idf0b7716b92a6a15bfe58721c2c34dbd02b31137 > Reviewed-on: https://chromium-review.googlesource.com/c/1270261 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > Cr-Commit-Position: refs/heads/master@{#56588} Change-Id: Iad23455f66c83340430370be6670bac493c638a1 Reviewed-on: https://chromium-review.googlesource.com/c/1309305 Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57705}
-
- 13 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I52660eeda1bd299953793af9af1395f47e89072e Reviewed-on: https://chromium-review.googlesource.com/c/1331155 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57454}
-
- 05 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
and split Smi out of objects.h into smi.h. Bug: v8:3770, v8:5402 Change-Id: I5ff7461495d29c785a76c79aca2616816a29ab1e Reviewed-on: https://chromium-review.googlesource.com/c/1313035Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57252}
-