- Remove flag --block-concurrent-recompilation and its implementation,
including %UnblockConcurrentCompilation.
- Rewrite tests that used it in terms of the primitives introduced in
my previous CL:
https://chromium-review.googlesource.com/c/v8/v8/+/3071400/
- Remove "sync"/"no sync" arguments from %GetOptimizationStatus,
assertOptimized, etc. These are now always "no sync": they don't
do any magic.
- Remove "if %IsConcurrentRecompilationSupported then quit" from some
tests in favor of --concurrent-recompilation in their Flags line.
Bug: v8:12041, v8:7790
Change-Id: I966aae4fec85e6f9e7aeed2ba2c12e9198a3991f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077149
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76298}
One of the subtests relies on that.
R=jgruber@chromium.org
Bug: v8:12069
Change-Id: I648a766baf4d977f4df607754f666bd9e9102168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086473
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76218}
Some tests want to invalidate part of the VM state after an optimization
has consumed the old state but before the code is installed.
The existing mechanism for this is --block-concurrent-recompilation
and %UnblockConcurrentRecompilation(). The former suspends optimization
right after PrepareJob, before the background ExecuteJob phase. The
intrinsic can then be used to unblock it again.
This was good enough so far because the main "consume" work used to
happen on the main thread. With concurrent inlining this is no longer
true and we need something else.
This CL introduces three intrinsics:
%DisableOptimizationFinalization turns off automatic finalization of
background optimizations.
%FinalizeOptimization() can then be called at an appropriate time to
manually finalize (and thus install) the code and reenable automatic
finalization.
In case one wants to perform some action on the main thread after the
concurrent optimization has finished but before it is finalized, one can
do so with the help of %WaitForBackgroundOptimization() (see tests).
In a followup CL I'm removing the old mechanism since it now seems
redundant.
Bug: v8:12041, v8:7790
Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76190}
Based on a CL by mvstanton@.
Bug: v8:7790,v8:12030,v8:12031,v8:12041
Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76055}
stress_flush_bytecode controls stress flushing of both bytecode and
baseline code. So rename the flag to better reflect its functionality
Bug: v8:11947
Change-Id: Ie6c124a476c3a7c6eabd1d75de030ee15fe78e32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062567
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76043}
Until this CL, the JSHeapBroker::GetPropertyAccessInfo (GPAI) process
was as follows:
1. GPAI is called on the main thread (MT) during the serialization
phase to create and cache PAIs.
2. GPAI is called again from the background thread (BT); only cached
PAIs from step 1 are usable.
As part of concurrent inlining, the goal is to move GPAI fully to the
background thread. This CL takes a major step in that direction by
making GPAI itself callable from the BT without resorting solely to PAIs
that were previously cached on the MT.
There are two main reasons why GPAI previously had to run on the MT:
a) Concurrent access to Maps and other heap objects.
b) Serialization and creation of ObjectRefs for objects discovered
during GPAI.
This CL addresses only reason a) and leaves b) for future work. This
is done by keeping the two-pass approach, s.t. the initial call of
GPAI on the MT discovers and serializes objects. We then clear all
cached PAIs. The second call of GPAI on the BT thus runs full logic in a
concurrent setting.
Once all relevant objects (= maps and prototypes) no longer require
MT-serialization, reason b) is also addressed and the first pass can be
removed.
The new logic is implemented behind the runtime flag
--turbo-concurrent-get-property-access-info (default true), intended
to be removed in the future.
Bug: v8:7790
Change-Id: Idbdbfe091d7316529246a686bb6d71c2a0f06f8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2817793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: 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@{#74120}
Bug: v8:11604
Change-Id: Ic4aa3ae64aa9c9a60aceade9072a5ead1c894b7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2799356
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73767}
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/2720300.
As compared to the original version, it adds
--no-stress-flush-bytecode to the const-dict-tracking.js test
Original description:
This CL is part of a series that implements Turbofan support for
property accesses satisfying the following conditions:
1. The holder is a dictionary mode object.
2. The holder is a prototype.
3. The access is a load.
This feature will only be enabled if the build flag
v8_dict_property_const_tracking is set.
This particular CL implements support for the case that the property
in question is an accesor, meaning that the given PropertyAccessInfo
has kind kAccessorDictionaryProtoConstant.
Bug: v8:11248
Change-Id: I896e5dc59821f88abdb7a743e21ca3a700af9db2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782280
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#73617}
This reverts commit b1883dc3e1.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/17269/overview
Original change's description:
> [dict-proto] TF support for constants in dictionary mode protos, pt. 3
>
> This CL is part of a series that implements Turbofan support for
> property accesses satisfying the following conditions:
> 1. The holder is a dictionary mode object.
> 2. The holder is a prototype.
> 3. The access is a load.
>
> This feature will only be enabled if the build flag
> v8_dict_property_const_tracking is set.
>
> This particular CL implements support for the case that the property
> in question is an accesor, meaning that the given PropertyAccessInfo
> has kind kAccessorDictionaryProtoConstant.
>
> Bug: v8:11248
> Change-Id: Id082107edd45fa91a3f1d96aa9df345a60f46917
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720300
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Frank Emrich <emrich@google.com>
> Cr-Commit-Position: refs/heads/master@{#73607}
Bug: v8:11248
Change-Id: Id753354a5ccddd1a05ecf9aec3267f152ef713c5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780299
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73612}
This CL is part of a series that implements Turbofan support for
property accesses satisfying the following conditions:
1. The holder is a dictionary mode object.
2. The holder is a prototype.
3. The access is a load.
This feature will only be enabled if the build flag
v8_dict_property_const_tracking is set.
This particular CL implements support for the case that the property
in question is an accesor, meaning that the given PropertyAccessInfo
has kind kAccessorDictionaryProtoConstant.
Bug: v8:11248
Change-Id: Id082107edd45fa91a3f1d96aa9df345a60f46917
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720300
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#73607}
This CL is part of a series that implements Turbofan support for
property accesses satisfying the following conditions:
1. The holder is a dictionary mode object.
2. The holder is a prototype.
3. The access is a load.
This feature will only be enabled if the build flag
v8_dict_property_const_tracking is set.
This particular CL implements support for the case that the property
in question is a data property, meaning that the given
PropertyAccessInfo has kind kDataDictionaryProtoConstant.
Support for accessor properties is added in a separated CL.
Bug: v8:11248
Change-Id: I8794127d08c3d3aed6ec2a3eb19c4c82bdf2d1df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718229
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73603}
For dictionary mode objects, whether or not a property is constant was
not tracked before. This CL makes the required non-Turbofan changes,
guarded behind the new flag V8_DICT_PROPERTY_CONST_TRACKING.
In addition, prototypes are not converted to fast mode objects if this
flags is enabled.
Bug: v8:11247
Change-Id: Ia5942733239a97560b6efc015f0e25a35fea3d7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566757
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72524}
