- 16 Oct, 2020 1 commit
-
-
Dominik Inführ authored
This is a reland of 44708a5b Original change's description: > [compiler, heap] Create LocalHeap outside of ExecuteJob > > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and > pass its reference as argument to ExecuteJob. This allows us to create > LocalHeap differently for the main and background thread, e.g. by > passing an additional argument to the constructor in the future. > It will be required in the future anyways when the main thread will > have its own LocalHeap/LocalIsolate. > > Extending the scope of LocalHeap, also made > HandleBase::IsDereferenceAllowed more precise and uncovered two > potential issues: heap accesses in > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode > with --code-comments. > > LocalHeap can now be created in the parked state. Also fixed a data > race with LocalHeap's destructor publishing write barrier entries > without holding the lock. > > Bug: v8:10315 > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70521} Bug: v8:10315 Change-Id: I4c459fd6dfb98d47fc9941c0dc6864bf5a1d2d3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474788Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#70560}
-
- 15 Oct, 2020 2 commits
-
-
Georg Neis authored
This reverts commit 44708a5b. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692 Original change's description: > [compiler, heap] Create LocalHeap outside of ExecuteJob > > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and > pass its reference as argument to ExecuteJob. This allows us to create > LocalHeap differently for the main and background thread, e.g. by > passing an additional argument to the constructor in the future. > It will be required in the future anyways when the main thread will > have its own LocalHeap/LocalIsolate. > > Extending the scope of LocalHeap, also made > HandleBase::IsDereferenceAllowed more precise and uncovered two > potential issues: heap accesses in > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode > with --code-comments. > > LocalHeap can now be created in the parked state. Also fixed a data > race with LocalHeap's destructor publishing write barrier entries > without holding the lock. > > Bug: v8:10315 > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70521} TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70522}
-
Dominik Inführ authored
Create LocalHeap directly in the Task or in GetOptimizedCodeNow and pass its reference as argument to ExecuteJob. This allows us to create LocalHeap differently for the main and background thread, e.g. by passing an additional argument to the constructor in the future. It will be required in the future anyways when the main thread will have its own LocalHeap/LocalIsolate. Extending the scope of LocalHeap, also made HandleBase::IsDereferenceAllowed more precise and uncovered two potential issues: heap accesses in OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode with --code-comments. LocalHeap can now be created in the parked state. Also fixed a data race with LocalHeap's destructor publishing write barrier entries without holding the lock. Bug: v8:10315 Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70521}
-
- 13 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
GetOwnElementFromHeap uses LookupIterator which requires heap allocation. Therefore, we cannot call it from the background thread with concurrent access. Bug: v8:7790, v8:11012 Change-Id: I29733db69a8935c7b7585c776ab1a2d7f1265e95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465841 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70488}
-
- 08 Oct, 2020 1 commit
-
-
Georg Neis authored
Bug: v8:7790 Change-Id: I1ffb2289f613a03d0246db2d66c3caaf0e4d6d2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448796 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#70406}
-
- 07 Oct, 2020 2 commits
-
-
Santiago Aboy Solanes authored
We had a way to do string to double without allocation that we were using on StringData. Reuse that on StringRef for Strings that can access the heap. BUg: v8:7790 Change-Id: I30e6dace3fbf05eb8672ff1bad46f6c6d6fe1d6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450013Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70384}
-
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}
-