- 17 Jun, 2021 1 commit
-
-
Dominik Inführ authored
MemoryChunkLayout::MaxRegularCodeObjectSize() can be cached in a global variable on process initialization. This should help to increase code object allocation performance, since this method was called on each code object allocation. Bug: v8:11891 Change-Id: I870bd37202370aec89ef2db24264e363099bf8a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966387 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#75215}
-
- 16 Jun, 2021 1 commit
-
-
Mike Stanton authored
In heap-refs.cc, GetOwnFastDataPropertyFromHeap() bottlenecks reading a fast property. To make it safe to use from the background thread we need to verify the object didn't shrink, and risk an out of heap bounds read. Bug: v8:7790 Change-Id: Idebbe0ffea089bf2a70aa7d611618430169082fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928185Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#75186}
-
- 15 Jun, 2021 1 commit
-
-
Georg Neis authored
I don't see any reason why we need to convert the 'uninitialized' Oddball into a Smi 0 in the Smi case, nor why we need to convert the hole-NaN HeapNumber into the Oddball in the Tagged case. These are temporary anyways. Change-Id: Ifdcd67528c7b19c36a1bde11291d78c3f211897f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953291Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#75151}
-
- 09 Jun, 2021 1 commit
-
-
Jakob Gruber authored
This is a step towards making JSObjectRef non-serialized. Change JSObjectRef::RawFastPropertyAt to use a direct load with relaxed semantics. Special handling of `uninitialized` sentinel values is moved to the only use-site. A new lock `boilerplate_migration_access` protects against concurrent boilerplate migrations while we are iterating over properties. Bug: v8:7790 Change-Id: Ic9de54ca16c1f3364d497a77058cfa33d48dd4a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928184 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#75033}
-
- 07 Jun, 2021 1 commit
-
-
Jakob Gruber authored
.. and replace them by elements read directly from the heap object. With this change, consistency between `map` and `elements` is no longer guaranteed. Users were updated, when necessary, to deal with this, e.g. by being more careful not to read out of bounds, by inserting new `actual_elements == elements_constant` runtime checks, or through a new compilation dependency that verifies unchanged elements at finalization time. Drive-by: inline GetElementsKind into callsites. Bug: v8:7790 Change-Id: Ifba78182e185ff0d4e954e3be52f0eb24328c853 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909655Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74977}
-
- 26 May, 2021 1 commit
-
-
Jakob Gruber authored
This is a reland of 6d99f933 No changes since revert. Original change's description: > [compiler] Replace EnsureElementsTenured by IsElementsTenured > > We can't mutate heap state from the compiler thread; turn this into a > predicate and emit generic code if it returns false. > > Bug: v8:7790 > Change-Id: I6186a87e178d0c0206b6e7659fa2a41bf65fd835 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876845 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74596} Tbr: neis@chromium.org Bug: v8:7790 Change-Id: I9cfdcf9929870a8314486292bab91e83cb448410 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917605Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74775}
-
- 18 May, 2021 1 commit
-
-
Sathya Gunasekaran authored
This reverts commit 6d99f933. Reason for revert: 4683d6fe broke TSAN, reverting all its dependencies first (including this) https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/36744/overview Original change's description: > [compiler] Replace EnsureElementsTenured by IsElementsTenured > > We can't mutate heap state from the compiler thread; turn this into a > predicate and emit generic code if it returns false. > > Bug: v8:7790 > Change-Id: I6186a87e178d0c0206b6e7659fa2a41bf65fd835 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876845 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74596} Bug: v8:7790 Change-Id: Ic32921a2f7d870560cd596933d6308a04d757e22 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2901986Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#74617}
-
- 17 May, 2021 1 commit
-
-
Jakob Gruber authored
We can't mutate heap state from the compiler thread; turn this into a predicate and emit generic code if it returns false. Bug: v8:7790 Change-Id: I6186a87e178d0c0206b6e7659fa2a41bf65fd835 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876845 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74596}
-
- 05 May, 2021 3 commits
-
-
Georg Neis authored
... in favour of an optional return type for MapRef::prototype(). This also eliminates one kind of use of ShouldHaveBeenSerialized(), which I want to get rid of entirely. Bug: v8:7790 Change-Id: I031f067d644570e5c8aaeaf94c5ff69ff0515a99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874456 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74385}
-
Jakob Gruber authored
This is part of a CL series that establishes MakeRef/TryMakeRef as the bottleneck for Ref construction. We do this by converting direct constructor uses to (Try)MakeRef calls, and then marking the ctor as protected. Bug: v8:7790 Change-Id: I26faa6bc1934662c81ae127dee64bddffa428de9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874165Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74371}
-
Jakob Gruber authored
This is part of a CL series that establishes MakeRef/TryMakeRef as the bottleneck for Ref construction. We do this by converting direct constructor uses to (Try)MakeRef calls, and then marking the ctor as protected. Bug: v8:7790 Change-Id: I36c07f69378f3a630462c216ef5da284cfd3972f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871449 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74367}
-
- 29 Apr, 2021 1 commit
-
-
Jakob Gruber authored
Drive-by: Fix type hierarchies of a few FixedArray-related classes. Done in this CL because it's based on the changes to FixedArrayData. Drive-by: Allow AllocateFastLiteral (now TryAllocateFastLiteral) to fail. Needed since currently ObjectRef creation may fail. Bug: v8:7790 Change-Id: I1f8cf35a16408ed0e327f12602c832838254bb03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2853592 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74265}
-
- 27 Apr, 2021 1 commit
-
-
Jakob Gruber authored
FixedDoubleArrays are a special case: 1 The reads are 64-bit and unaligned, thus use memcpy underneath. 2 The compiler only reads FDArray values for (constant) boilerplate elements. 1) makes proper atomic reads tricky-to-impossible without a lock. Luckily, 2) means we know that the array values are immutable after initialization, thus we can simply do a non-atomic read from the compiler thread. Bug: v8:7790 Change-Id: I39698d867543ce2214a2148511c5d90ced6364b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848410 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74226}
-
- 13 Apr, 2021 1 commit
-
-
Maya Lekova authored
The CanAllocateArray used to be executed during JSCreateLowering, leading to bailouts when large arrays are passed as arguments to an async function or a bound function. This meant that JSCreateAsyncFunctionObject or JSCreateBoundFunction will reach JSGenericLowering, where they are not lowered. This CL moves the checks earlier in the pipeline during JSNativeContextSpecialization and JSCallReducer respectively, so that those operators are not created at all in such cases and we bail out to the runtime instead. Bug: v8:11564 Change-Id: I232ce7d9378730ae0cc8690e52fde840a484e069 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2807609 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#73928}
-
- 12 Apr, 2021 1 commit
-
-
Wenyu Zhao authored
This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
-
- 22 Feb, 2021 1 commit
-
-
Jakob Gruber authored
This is a reland of 76a2ab06 Changes since the original CL: - Handle unserialized elements (optional result in getter). - Merge should_access_heap and --turbo-direct-heap-access paths. - Slightly update the serialized path in GetOwnCowElement. - Fix the cctest, add a regression test. Atomic JSObject::elements/JSArray::length setters are addressed in this CL: crrev.com/c/2704076. Original change's description: > [compiler] Direct heap reads for JSArrayRef > > There are two aspects to the non-JSObject parts of JSArrayRef: > > - JSArrayRef::length. Relevant only in two spots, 1. when reading > (immutable) array boilerplates and 2. for GetOwnCowElement. > > - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing > store. Relies on the invariant that cow backing stores are immutable. > > This CL renames the length accessor to length_unsafe to make the > danger explicit at callsites. > > For GetOwnCowElement the refactor is slightly larger, since we now > need to read into the backing store while keeping full control of > object reads (e.g. JSArray::length and JSArray::elements_kind). We > make all reads explicit at the call site by requiring that elements, > elements kind, and length are passed in as arguments to > GetOwnCowElement. Inside GetOwnCowElement, consistency between these > is *not* guaranteed due to concurrency. At runtime, consistency *is* > guaranteed through the reference-equality check on the elements seen > during compilation. The actual elements read is implemented in > ConcurrentLookupIterator::GetOwnCowElement. > > Bug: v8:7790 > Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72834} Bug: v8:7790 Change-Id: I7577ad554992cafff81099a28c34f27db9bd8042 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710431 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72904}
-
- 19 Feb, 2021 1 commit
-
-
Georg Neis authored
This reverts commit 76a2ab06. Reason for revert: A few issues, e.g. https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8854931126653780144/+/u/Check__flakes_/ArrayWithCowElements Original change's description: > [compiler] Direct heap reads for JSArrayRef > > There are two aspects to the non-JSObject parts of JSArrayRef: > > - JSArrayRef::length. Relevant only in two spots, 1. when reading > (immutable) array boilerplates and 2. for GetOwnCowElement. > > - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing > store. Relies on the invariant that cow backing stores are immutable. > > This CL renames the length accessor to length_unsafe to make the > danger explicit at callsites. > > For GetOwnCowElement the refactor is slightly larger, since we now > need to read into the backing store while keeping full control of > object reads (e.g. JSArray::length and JSArray::elements_kind). We > make all reads explicit at the call site by requiring that elements, > elements kind, and length are passed in as arguments to > GetOwnCowElement. Inside GetOwnCowElement, consistency between these > is *not* guaranteed due to concurrency. At runtime, consistency *is* > guaranteed through the reference-equality check on the elements seen > during compilation. The actual elements read is implemented in > ConcurrentLookupIterator::GetOwnCowElement. > > Bug: v8:7790 > Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72834} Bug: v8:7790, chromium:1180012 Change-Id: I50e72380c544b2b78e1e3dc87a8249281b710912 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704666 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72860}
-
- 18 Feb, 2021 1 commit
-
-
Jakob Gruber authored
There are two aspects to the non-JSObject parts of JSArrayRef: - JSArrayRef::length. Relevant only in two spots, 1. when reading (immutable) array boilerplates and 2. for GetOwnCowElement. - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing store. Relies on the invariant that cow backing stores are immutable. This CL renames the length accessor to length_unsafe to make the danger explicit at callsites. For GetOwnCowElement the refactor is slightly larger, since we now need to read into the backing store while keeping full control of object reads (e.g. JSArray::length and JSArray::elements_kind). We make all reads explicit at the call site by requiring that elements, elements kind, and length are passed in as arguments to GetOwnCowElement. Inside GetOwnCowElement, consistency between these is *not* guaranteed due to concurrency. At runtime, consistency *is* guaranteed through the reference-equality check on the elements seen during compilation. The actual elements read is implemented in ConcurrentLookupIterator::GetOwnCowElement. Bug: v8:7790 Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#72834}
-
- 16 Feb, 2021 1 commit
-
-
Georg Neis authored
My previous CL was missing a negation in two places. Bug: chromium:1178731 Change-Id: I5bc4d78226e43a62ddd374c3d7dd36a9ed0c1a2f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697192 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72775}
-
- 15 Feb, 2021 1 commit
-
-
Georg Neis authored
... otherwise we'd abort at runtime. Bug: chromium:1178076 Change-Id: Ic7b4a3b27379ec0d42419e2695ab487904eabd72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695395Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72744}
-
- 12 Feb, 2021 1 commit
-
-
Georg Neis authored
This reverts commit 87df0b7e (thus relands 42cd9eb7), with fixes for the discovered issues. Original change's description: > Revert "[compiler] Directly read PropertyCells" > > This reverts commit 42cd9eb7. > > Reason for revert: Clusterfuzz issues, e.g. > https://bugs.chromium.org/p/chromium/issues/detail?id=1176318 > > Original change's description: > > [compiler] Directly read PropertyCells > > > > Main changes: > > > > - Introduce a new broker data kind kBackgroundSerialized for objects > > that can be serialized in the background (when direct reads are on). > > (I'm planning to remove kPossiblyBackgroundSerialized in a followup, > > in favor of a dynamic choice of kSerialized or kBackgroundSerialized). > > - Make PropertyCell use that new kind. > > - Introduce a bottleneck in runtime code for changes to PropertyCells > > and make sure that a certain protocol is followed that allows > > concurrent reads from the background thread. > > - Improve interface of PropertyCell in various ways. > > > > Bug: v8:7790 > > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > > Commit-Queue: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#72586} > > TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org > > Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180 > Bug: v8:7790 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72619} Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504 Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72697}
-
- 11 Feb, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Reasons: * We disabled it more than a year ago for all configs * Not easy to re-enable * Not compatible with pointer compression as-is * Not compatible with concurrent TP/TF as-is * No concrete plans to re-enable it Also remove Map's layout_descriptor since it was only used for double field unboxing. Bug: v8:11422 Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72671}
-
- 10 Feb, 2021 1 commit
-
-
Georg Neis authored
This reverts commit 42cd9eb7. Reason for revert: Clusterfuzz issues, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1176318 Original change's description: > [compiler] Directly read PropertyCells > > Main changes: > > - Introduce a new broker data kind kBackgroundSerialized for objects > that can be serialized in the background (when direct reads are on). > (I'm planning to remove kPossiblyBackgroundSerialized in a followup, > in favor of a dynamic choice of kSerialized or kBackgroundSerialized). > - Make PropertyCell use that new kind. > - Introduce a bottleneck in runtime code for changes to PropertyCells > and make sure that a certain protocol is followed that allows > concurrent reads from the background thread. > - Improve interface of PropertyCell in various ways. > > Bug: v8:7790 > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72586} TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180 Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72619}
-
- 09 Feb, 2021 1 commit
-
-
Georg Neis authored
Main changes: - Introduce a new broker data kind kBackgroundSerialized for objects that can be serialized in the background (when direct reads are on). (I'm planning to remove kPossiblyBackgroundSerialized in a followup, in favor of a dynamic choice of kSerialized or kBackgroundSerialized). - Make PropertyCell use that new kind. - Introduce a bottleneck in runtime code for changes to PropertyCells and make sure that a certain protocol is followed that allows concurrent reads from the background thread. - Improve interface of PropertyCell in various ways. Bug: v8:7790 Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72586}
-
- 04 Feb, 2021 1 commit
-
-
Jakob Gruber authored
... and mark it as never-serialized wrt turbofan serialization. Until this CL, the JSRegExp type was used as both for plain user-visible regexp objects, and for internal regexp boilerplate descriptions. Boilerplates are special: they are never exposed to the user, they are only referenced from the feedback vector, they are immutable. To clarify this distinction, this CL introduces a dedicated struct type RegExpBoilerplateDescription to hold the regexp boilerplate description. This makes Turbofan serialization simpler: boilerplates can be accessed through direct reads since they are immutable. TF has no special requirements on JSRegExp objects (it never reads into these objects) and thus serializing only the references as a JSObjectRef is fine. Bug: v8:7790 Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72522}
-
- 22 Jan, 2021 1 commit
-
-
Victor Gomes authored
After removing the arguments adaptor frame, this should not be needed anymore. Removes ArgumentFrame from the following nodes: - ArgumentsLength - RestLength - NewArgumentsElements Also removes 'formal parameter count' as input of ArgumentsLength. Adapt the escape analysis to use the frame pointer directly instead of the ArgumentsFrame node. Change-Id: I0ead48a6ee05a10d05d6cfa2e46906ad69930986 Bug: v8:11306 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639765 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72264}
-
- 21 Jan, 2021 1 commit
-
-
Jakob Gruber authored
The `parameters` attached to FrameState nodes are often iterated s.t. the receiver (implicitly at index 0), and potentially some leading parameters, are skipped. The new convenience functions `begin_without_receiver` and `begin_without_receiver_and_skip` make this pattern more convenient. Bug: chromium:1166136 Change-Id: Ic2bc7319edf9b8567346788dfaebd8852672a703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637221 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72211}
-
- 20 Jan, 2021 1 commit
-
-
Jakob Gruber authored
Move index constants into the wrapper, add getters, and use the wrapper in more spots. Bug: v8:1166136 Change-Id: I3f37a541482fd6b7c604719c759952a72d58bad2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637218 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72198}
-
- 03 Dec, 2020 1 commit
-
-
Leszek Swirski authored
TurboFan creates DisallowHeapAccess scopes, to prevent heap access in the concurrent parts of the compiler. Then, for parts of the compiler that do want to access the heap, it either creates Allow* scopes (which should be avoided since they "punch a hole" in the Disallow* scopes), or relies on a weakening of Handle::IsDereferenceAllowed which allows handles owned by a LocalHeap to be dereferenced even if there is a DisallowHeapDereference scope. This patch: a) Strengthens the implicit requirements around handle dereferencing to require a running heap on this thread (either main-thread heap or an un-parked, un-safepointed LocalHeap). b) Removes the overly strict Disallow scopes in TurboFan, relying instead on implicit requirements for allocation/handle dereferencing in off-thread code. c) Cleans up the "should_disallow_heap_access" predicate to be more explicit about what should be disallowed (e.g. property accesses can't be computed concurrently) Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71600}
-
- 13 Nov, 2020 1 commit
-
-
Nico Hartmann authored
This is the 2nd step in series of CLs to move the SharedFunctionInfo class to kNeverSerialized and make it concurrently accessible from the background thread. This CL: * Changes optimization of GetTemplateObject in JSCreateLowering to only perform the optimization of a template object exists in the SharedFunctionInfo[Ref], but skips the optimization if one is missing instead of allocating a new one on demand. Bug: v8:7790 Change-Id: Ic37d8333676e54b3f8d69416480df12bd90723ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463229 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71189}
-
- 30 Oct, 2020 1 commit
-
-
Georg Neis authored
After c90ff8bd this is purely a cosmetic change. Change-Id: If804f1b7558ab2f8096e576570f68b848df7423c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509592Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70900}
-
- 28 Oct, 2020 1 commit
-
-
Tobias Tebbi authored
This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 25 Sep, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 64caf2b0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-
- 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}
-
- 22 Sep, 2020 2 commits
-
-
Francis McCabe authored
This reverts commit 64caf2b0. Reason for revert: Seems to be causing a failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809? Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} TBR=jgruber@chromium.org,tebbi@chromium.org Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
Tobias Tebbi authored
This is to establish a naming rule for Torque-generated files: - If the file is called foo/bar-tq..., then it is derived from a file foo/bar.tq - Otherwise it doesn't belong to a specific .tq file. So far, we attached -tq to all Torque-generated file names, where it sometimes corresponded to a .tq file name and sometimes not. It is not necessary to add -tq to file names to indicate that they are Torque-generated, since they are already in a directory called torque-generated, and we always refer to them as "torque-generated/filename", so there is no confusion even though some files now have the same name as a corresponding hand-written file, for example factory.cc. TBR: hpayer@chromium.org Bug: v8:7793 Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70060}
-
- 29 Jul, 2020 1 commit
-
-
Victor Gomes authored
Change-Id: I41be2c5b0867739dbbe3667144bf6b479c609e53 Bug: chromium:1107221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2322628 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69122}
-
- 16 Jul, 2020 2 commits
-
-
Mythri A authored
We cannot allocate large arrays exceeding the size of kMaxRegularHeapObjectSize in young space. Bailout of optimization in such cases. Bug: chromium:1105746 Change-Id: I4f7357c2dd7b3e70d747f9067660725ecf6ae768 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300481Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#68889}
-
Victor Gomes authored
Rest arguments were using the builtin NewArgumentsElements to create its backing store. This does work when the rest elements are a suffix of the arguments in the stack, but this is not the case when V8_REVERSE_JSARGS is enabled. This CL ports the builtin to Torque and fix the previous issues with V8_REVERSE_JSARGS. Change-Id: I82db0dfd409d909336f34312f62c379ca5929e1e Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284988Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68888}
-
- 07 Jul, 2020 1 commit
-
-
Jakob Gruber authored
HasProperty and InstanceOf now both have a feedback vector input, and collect feedback in generic lowering. CreateClosure loads the feedback cell (in nci mode) instead of embedding a heap constant. Bug: v8:8888 Change-Id: Id479cda344684aeb5054f687b087c4fedeac05d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282530Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68711}
-