- 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}
-
- 06 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: Ia3902c8f12e856a2879e58de496cdf6291267496 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450199 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70350}
-
- 05 Oct, 2020 3 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}
-
Leszek Swirski authored
Remove the pattern of calling 'Find' followed by 'Set' for IdentityMap, with a single 'FindOrInsert' that explicitly returns whether an existing entry was found, or the entry was inserted. This replaces 'Get', which would return either an initialised or uninitialised entry (and callers would rely on default initialisation to check this). Also replace 'Set' with 'Insert', which explicitly requires that the element didn't exist before. This matches expectations where it was used (where those weren't replaced wholesale with 'FindOrInsert'), and makes the naming consistent with 'FindOrInsert'. Change-Id: I8fb76f4ac14fb92b88474965aafb1ace5fb79145 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443135 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#70300}
-
- 30 Sep, 2020 2 commits
-
-
Mike Stanton authored
CallHandleInfos are observed for optimizing API calls in TurboFan. The place to be careful is on allocation and installation of these objects in a FunctionTemplate. As long as store order is preserved there, we can safely directly access the class members. Bug: v8:7790 Change-Id: I6acb318d01c19d97725c7218e913765c33e0d8b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435096 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#70236}
-
Jakob Gruber authored
Turboprop-generated Code objects will now have the dedicated TURBOPROP code kind instead of OPTIMIZED_FUNCTION. When possible, the code kind is used as the source of truth instead of FLAG_turboprop. This is the initial step towards implementing tier-up from Turboprop to Turbofan. Future work: Rename OPTIMIZED_FUNCTION to TURBOFAN, rename STUB to DEOPT_ENTRIES_OR_FOR_TESTING, implement TP tier-up. No-Try: true Bug: v8:9684 Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Change-Id: I3c9308718d7e9a2b7e6796e7ea94f17e5ff84c0a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424140 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70213}
-
- 29 Sep, 2020 2 commits
-
-
Georg Neis authored
This reverts commit d734bb4c. Reason for revert: Flawed. Original change's description: > [compiler] Check for stack overflow in recursive ReduceJSCall > > Gracefully handle hugely nested JSBoundFunctions. > > Bug: chromium:1125145 > Change-Id: I08f136fa9d35cf16ea8da5132d4d483a75d0ba94 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418091 > Auto-Submit: Georg Neis <neis@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70164} TBR=neis@chromium.org,mslekova@chromium.org Change-Id: I2d4ed79e2470981dab7ccba8e0c7e1004fe91369 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1125145 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436342Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70195}
-
Santiago Aboy Solanes authored
Reverted: * FixedDoubleArray * BigInt * HeapNumber * Partial work of JSDataView Bug: v8:7790 Change-Id: I075e1d6d50129771f6208f198911797c6db3b7cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431944 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70187}
-
- 28 Sep, 2020 2 commits
-
-
Mythri A authored
For loads like Array.prototype.push, using dynamic map checks for loading loading "push" from array prototype would prevent constant folding of the push builtin. This would prevent inlining of these builtins in the later phases. So, disable dynamic map checks when loading fields from array prototype. Bug: v8:10582 Change-Id: I8b44392a81194a3a5bd9b5ced6b1175658cec1f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435367 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70171}
-
Georg Neis authored
Gracefully handle hugely nested JSBoundFunctions. Bug: chromium:1125145 Change-Id: I08f136fa9d35cf16ea8da5132d4d483a75d0ba94 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418091 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70164}
-
- 24 Sep, 2020 1 commit
-
-
Santiago Aboy Solanes authored
When reading the FixedDoubleArray value and representation, we are reading the same value but bitcasting it diffrently. In this vein, we can read it only once and ask whether it is the hole or not. Bug: v8:7790 Change-Id: I0d7b29ce037b9abb55c5a1332c7e6d06887905e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428587Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70119}
-
- 17 Sep, 2020 2 commits
-
-
Santiago Aboy Solanes authored
Replace the SourceTextModuleRef::GetCell method. Bug: v8:7790 Change-Id: I65e2f121b9d37c39e5d208d68409f61724ce198e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410192Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69966}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I2f0c2fdcb44c216471a8778816b9e041478f0792 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410191Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69965}
-
- 16 Sep, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This is a reland of b5f37051 Got reverted since it was breaking the bots (https://bugs.chromium.org/p/v8/issues/detail?id=10918) The solution is to keep the JSDataView class as kSerialized but change its method to do a direct heap access. In this way, its map it will still be serialized (which was the cause of the bot failure). In order to keep incrementally skipping serialization, we can introduce new macros that allow a per-method skip of serialization rather than per-class. Original change's description: > [compiler] Replace JSDataView with direct reads > > Bug: v8:7790 > Change-Id: Id01c2e4359aa4294816ffe14c08a586a9b9b10c2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404768 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69904} Bug: v8:7790, v8:10918 Change-Id: Ifdfe504272369e7cc1332fe53992739f9d0be385 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413258Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69949}
-
- 15 Sep, 2020 4 commits
-
-
Santiago Aboy Solanes authored
This reverts commit b5f37051. Reason for revert: Breaking the fuzzer https://bugs.chromium.org/p/v8/issues/detail?id=10918 Original change's description: > [compiler] Replace JSDataView with direct reads > > Bug: v8:7790 > Change-Id: Id01c2e4359aa4294816ffe14c08a586a9b9b10c2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404768 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69904} Change-Id: I9a470708f06328061d5d4ecf21fa38bc0e49ff45 Bug: v8:7790, v8:10918 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410196Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69911}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I5391c6688dfad81e37d260fbfef22c3dbdce0dce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404769 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69905}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: Id01c2e4359aa4294816ffe14c08a586a9b9b10c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404768 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69904}
-
Georg Neis authored
Bug: v8:7790 Change-Id: I27a13c213c33e742cd66ed85e9c10c71b78a9384 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410182 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69902}
-
- 11 Sep, 2020 4 commits
-
-
Mythri A authored
We used to store MinimorphicPropertyAccessInfo indexed on the feedback slot id. This works fine when there is no inlining but returns the wrong access information when functions are inlined. Index it based on FeedbackSource to avoid these problems. Bug: v8:10582,chromium:1125871 Change-Id: Id01010f3153f7e21495d73899a8604a64417ae95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401426 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69845}
-
Santiago Aboy Solanes authored
Since the AllowHandleDereference scope doesn't happen for kNeverSerialized (see https://crrev.com/c/v8/v8/+/2402033), there is no need to have the extra if. Bug: v8:7790 Change-Id: I4c9f93d2e754625e7b30aee61e2b502161bd60c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404770 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69843}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: Ib0c95f27d21e4aea09dcc9804a800b16440a2fe2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403254Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69835}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I0e58244a679d5fd7f597c90c6f41ac255024de3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403253Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69834}
-
- 10 Sep, 2020 7 commits
-
-
Santiago Aboy Solanes authored
This is a reland of d3b295fa Got speculatively reverted in https://crrev.com/c/v8/v8/+/2403256 but doesn't seem to have been causing the TSAN failures Original change's description: > [compiler] Replace Symbol with direct reads > > Bug: v8:7790 > Change-Id: I49120a6349777fd992a97d697940e79b2e71dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400988 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69812} Bug: v8:7790 Change-Id: I459f4bfc881c641258dcc46fc55fce21f9e03dec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403921 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69822}
-
Sathya Gunasekaran authored
This reverts commit d3b295fa. Reason for revert: speculative revert for https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33146? Original change's description: > [compiler] Replace Symbol with direct reads > > Bug: v8:7790 > Change-Id: I49120a6349777fd992a97d697940e79b2e71dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400988 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69812} TBR=neis@chromium.org,solanes@chromium.org Change-Id: I10f69213e906e9b482ce4f8456ed7d5bcb039051 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403256Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#69815}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I49120a6349777fd992a97d697940e79b2e71dbd1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400988 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69812}
-
Santiago Aboy Solanes authored
Namely: * ObjectBoilerplateDescription * ArrayBoilerplateDescription Bug: v8:7790 Change-Id: I05d106b5e557604e67e0cebaef7489fa3faf3562 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398641 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69811}
-
Georg Neis authored
- Simplify some macros. - Simplify some handle creations. - Make various accessors more uniform. - Remove leftover assumptions about serialized children. Change-Id: Iee2951065c442aba1b479a48de33f0b8e0c7b057 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402033 Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69807}
-
Georg Neis authored
My last CL introduced a null-pointer bug there. Bug: chromium:1126771, v8:7790 Change-Id: Ib16317dea14c9fbad7951cb28ce7bb8bb9ce41c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402037 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69799}
-
Mythri A authored
Monomorphic loads are quite common and it is important to keep these load accesses fast. Dynamic map checks increases the overhead for these monomorphic accesses by having to actually verify the IC state and check against a map from the feedback vector This was causing a significant (~2-3%) regression in JavaScript duration. To keep the common case of monomorphic checks fast, we now want to add a check against expected map (which passes in most cases) and move the rest of the checks to a builtin. i.e. we want dynamic map checks (when generating the code for loads in monomorphic state) to look like: if (incoming_map != HeapConstant(expected_map)) call_builtin; This helps us to keep the most common case fast and still gets the benefits of dynamic map checks. This cl is the first in the series of cls that will add this functionality. This cl makes the expected_map available for dynamic map checks operator. In follow up cls, we will add a builtin and update the code to use the builtin. Bug: v8:10582 Change-Id: I10992c6ba1fb005592de962310c208cff6829119 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397894Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69798}
-
- 09 Sep, 2020 1 commit
-
-
Georg Neis authored
1) Strengthen the ObjectData::As* cast methods to check that the kind is kSerializedHeapObject, because otherwise the data object is not a subclass instance and the cast is invalid. 2) Fix errors revealed by (1) and pave way for moving away from serialization. These changes are mechanical except for a needed refactoring of ContextRef::previous. Details regarding (2): Change (1) revealed a large number of places where we incorrectly casted object data. This went unnoticed so far because in the end we accessed the object through the corresponding ObjectRef interface which did the right thing depending on the data kind. These bugs were introduced when kUnserializedReadOnlyHeapObject was added, but they also affect the new kNeverSerializedHeapObject and would become show stoppers as we move more objects to the latter kind. The CL fixes all the issues that I found except one: There's still one place left where we assume a particular subclass instance for now (marked with a TODO). This is not a bug at the moment but will cause CHECK failures once we move the corresponding object type to never-serialized. A rewrite of map serialization might be needed to resolve that. Note: With the changes in (2) we lose some type safety in the implementation of the *Data classes. With some extra work that could be avoided. However, I think it's not worth it because (i) these classes are expected to be removed (and in the meantime to not change much), and (ii) their wrapper *Ref classes still ensure type safety. Bug: v8:7790 Change-Id: I9a5d03fa2f61e03c9c0ab4ac7f9869603d5be1d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398537Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69775}
-
- 08 Sep, 2020 3 commits
-
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I0194178cd73715b2a7e229dd7ce52a67c2280881 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382312 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69743}
-
Santiago Aboy Solanes authored
Original CL by neis@: http://crrev.com/c/v8/v8/+/2362693/1 Bug: v8:7790, v8:10853 Fixed: v8:10853 Change-Id: If0bd45e9dfb00f8ef1a358953dab1f5e1c9ae29e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387960Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69742}
-
Santiago Aboy Solanes authored
It does a direct access iff the FLAG_turbo_direct_heap_access is enabled. Otherwise, it uses the Data classes as it did before. Bug: v8:7790 Change-Id: I4f42e5734fdb2c91dbe9ef08869aec621c9d04c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382311 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69737}
-
- 03 Sep, 2020 1 commit
-
-
Santiago Aboy Solanes authored
There are some objects that are serialized with concurrent inlining off even when they are part of HEAP_BROKER_NEVER_SERIALIZED_OBJECT_LIST. Bug: v8:7790 Change-Id: I91aa0e9d93cf86e2765f1f56bcfb8456c4b7685e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382310 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69701}
-
- 26 Aug, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This is a partial reland of 7b9a0c20 Reason for reland: Reverted since the ScopeInfoData part was causing issues. Relanding the macro structure, which shouldn't cause issues and it is needed for other CLs. Original changes description: > [compiler] Replace ScopeInfoData with direct reads > > As part of this, introduce a new ObjectData kind for objects that we > want to read directly from the background thread rather than serialize. > ScopeInfoRef is the first user of that. > > For details, see: > https://docs.google.com/document/d/1U6x6Q2bpylfxS55nxSe17yyBW0bQG-ycoBhVA82VmS0/edit?usp=sharing > > Bug: v8:7790 > Change-Id: Ia3cda4f67d3922367afa4a5da2aeaae7160cf1f2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346405 > Auto-Submit: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69473} Bug: v8:7790 Change-Id: I8d13dc206bb319638e3f7209446c24d06a07c110 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377690 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69573}
-
- 25 Aug, 2020 1 commit
-
-
Dominik Inführ authored
This reverts commit f16d3abf. Reason for revert: register_count() is read from the heap on the background thread. This is only safe when FLAG_local_heaps is enabled (set to true) but this isn't the case on tip-of-tree. Original change's description: > [compiler] Access the heap for BytecodeArray int/Register members > > We can create a new macro to skip the xxxData classes and read directly > from the heap. > > Bug: v8:7790 > Change-Id: I8de9ba0aee78c74d4c3113eb6bc4870a314de552 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362687 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69471} TBR=neis@chromium.org,solanes@chromium.org Bug: v8:7790 Change-Id: I35bdd44721ce1e9d2f46df7cf5d1f413e22d9acf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2372602Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69547}
-
- 20 Aug, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This is a reland of ad68de6f Reason for reland: Reverted since another CL got reverted. This cleanup is independent though and can be relanded. Original changes description: > [compiler] Remove unused holder parameter from IF_ACCESS_FROM_HEAP(_C) > > Bug: v8:7790 > Change-Id: I44849f45d1049b8a3c794dd0558b734c1e7061fd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362919 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69482} Bug: v8:7790 Change-Id: Ib650ef1701168be7a910ff51e30a90e239d5f5c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366774 Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#69496}
-
- 19 Aug, 2020 2 commits
-
-
Clemens Backes authored
This reverts commit 7b9a0c20. Reason for revert: Different tests start flaking, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/29532 Original change's description: > [compiler] Replace ScopeInfoData with direct reads > > As part of this, introduce a new ObjectData kind for objects that we > want to read directly from the background thread rather than serialize. > ScopeInfoRef is the first user of that. > > For details, see: > https://docs.google.com/document/d/1U6x6Q2bpylfxS55nxSe17yyBW0bQG-ycoBhVA82VmS0/edit?usp=sharing > > Bug: v8:7790 > Change-Id: Ia3cda4f67d3922367afa4a5da2aeaae7160cf1f2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346405 > Auto-Submit: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69473} TBR=neis@chromium.org,solanes@chromium.org,nicohartmann@chromium.org Change-Id: Ide5a4a583547b63cc9accfb93fcadb97b8100e8a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364504Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69487}
-
Clemens Backes authored
This reverts commit ad68de6f. Reason for revert: Previous CL needs to be reverted (https://crrev.com/c/2364504) Original change's description: > [compiler] Remove unused holder parameter from IF_ACCESS_FROM_HEAP(_C) > > Bug: v8:7790 > Change-Id: I44849f45d1049b8a3c794dd0558b734c1e7061fd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362919 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69482} TBR=solanes@chromium.org,nicohartmann@chromium.org Change-Id: Iffc7a44faec8a03583aa968271a5d0e6317317a7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364506Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69486}
-