Some tests disabled dynamic tiering in order to actually serialize
TurboFan code. This makes the tests a bit simpler, but does not reflect
real-world usage.
This CL enables dynamic tiering in those tests and when needed executes
the code until tier-up was observed.
R=ahaas@chromium.org
Bug: v8:12899
Change-Id: I34cb8cedbc5908d9e6ca09d56c51609d0c8b2d6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3660262
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80849}
This is a reland of a7d6bf9662
Added perfetto to unittests include_rules.
Bug: v8:12781
Change-Id: Iabf0e62abb1de879de21ba06fbd38f5432ee4f76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652295
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80847}
The abstractions in this CL include:
1) Using EvacuatePrologue to handle age mark updating in
SemiSpaceNewSpace.
2) Using IsPromotionCandidate to check if a page contains
the current age mark.
3) EnsureCurrentCapacity instead of Rebalance.
4) Delegate page promotions in mark-compact.cc to the
NewSpace implementation.
Bug: v8:12612
Change-Id: Ied83261d661a8e61a11bf33b1d7a2103ac99a853
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644966
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80846}
This reverts commit ff84cd0433.
Reason for revert: This CL had a commit from another branch
which was supposed to land as a part of that CL
( https://chromium-review.googlesource.com/c/v8/v8/+/3672415/1 ),
not this one.
Going to reland a cleaned up version.
Original change's description:
> [rab/gsab] Fix ObjectSerializer
>
> Without this fix, the byte length for GSABs is probably serialized
> wrong. A failing test is omitted since it would be pretty involved
> (currently this code path is only hit with --stress-snapshot).
>
> Bug: v8:11111
> Change-Id: If7df98263cec9f82766c2fa6ba095b98b53a6fde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3657431
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80780}
Bug: v8:11111
Change-Id: I5fc3384484f6a8d2d6e40a404da0bf04167abc1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3678838
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80845}
To eliminate unnecessary move instructions from register to fixed register. We check the fixed register hint for operands in move gaps
when building LiveRanges. If a to_operand has a hint_operand (with fixed register), then set the hint_operand for from_operand too. This can avoid the register allocator ignore hint information about fixed register.
Bug: v8:12909
Change-Id: I17f9afa484ee08de8ac1ab42945caba2c362fc9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669019
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Jialu Zhang <jialu.zhang@intel.com>
Cr-Commit-Position: refs/heads/main@{#80844}
The fuzzer runs the same wire bytes through the streaming decoder and
through synchronous compilation, and compares the result. In particular,
if one fails, then also the other should fail.
More checks for the result of both pipelines can be added later.
R=ahaas@chromium.org
Bug: v8:12922
Change-Id: I905adf740e581c4b7d0f4ab7c0d5d0e48d96fc4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3675100
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80842}
WorkerThreads access the queue to get new tasks, that's why all of
them need to stop before we can destroy the queue.
This hopefully fixes the linked race/crash since I can't reproduce
this locally.
Bug: v8:12914
Change-Id: Icbfd462f106a4a1f0bbd525f0b7f342e9857a539
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3672421
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80841}
Replace all usages of UPDATE_WEAK_WRITE_BARRIER with
UPDATE_WRITE_BARRIER. The barrier wasn't hot, so the additional branch
for the marking barrier shouldn't be a problem.
Performing the marking barrier could in theory cause more floating
garbage. However in this case the write barrier is only run once
directly after e.g. allocating a Code or NativeContext object. Since
UPDATE_WEAK_WRITE_BARRIER only skips the marking barrier, we should only
observe different behavior when marking is on. But since we already
have black allocation for objects in old space, we will not cause
additional floating garbage.
In case of performance regression, we should also be able to replace
those usages with SKIP_WRITE_BARRIER, since NativeContext and Code
objects are never allocated in the young generation, so running the
generational barrier shouldn't be necessary. It's just hard to DCHECK
that SKIP_WRITE_BARRIER is valid here.
Bug: v8:11708
Change-Id: I25d760a46d1d7ec973cc589f51ddf80ca3b5419d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663080
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80839}
If the optimized code is deoptimized and the deoptimized exit offset is
inside of the optimized OSR code related loop, the optimized OSR code is
also out of date, remove the optimized OSR code, it will avoid hit the
optimized OSR code and soon later deoptimization of the optimized OSR
code.
This CL will reduce deoptimization. E.g. Deoptimization of JetStream2
case navier-stokes function addFields is reduced from twice to once.
Change-Id: I5bbf3039e916c3736b5b967d1f36b6ea90cfd40b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3648219
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tao Pan <tao.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#80826}
This is a reland of commit c8848cf493
This change was reverted due to a problem in a preceding change. This
relanded version differs in its implementations of the
CompilationCacheScript member functions Lookup, Put, and Age, because
the intent is to not change any behavior.
Original change's description:
> CompilationSubCache has some complexity regarding generations of tables
> which is only used by one subclass, CompilationCacheRegExp. This change
> adjusts the class hierarchy so that classes only contain the necessary
> member functions.
>
> Bug: v8:12808
> Change-Id: I4f4cf15bbf9b80c2de0c18aea82a0c238804759d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629603
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#80506}
Bug: v8:12808
Change-Id: Ib0621b7de8da86a89752c66907f6a56adff9075d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3665936
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80825}
Allow fast branches in the case the accumulator's live range doesn't
extend beyond the branch test. Previously we were more restrictive and
only allowed fast branches the test itself didn't use the accumulator
register.
Bug: v8:7700
Change-Id: Iec98028b3ddb04eeb51e98436a0bdc48f22920ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663744
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80819}
NativeContexts are always allocated in old space and thus cannot die
or move during minor GCs.
Bug: v8:11708
Change-Id: I01ec7775aa1186d91ca620c464f570f24ac9f215
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666617
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80818}
The number of fields gets huge, and we get a lot of repetitive code. Use
a macro to simplify things.
R=jkummerow@chromium.org
Bug: v8:12425
Change-Id: I5282d03724fb7fe966ac9b281398adabfd339dcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667505
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80817}
Get some test coverage before restarting the map space compaction finch
again. This should test whether slots in invalidated objects are now
properly ignored when the invalidated object is dead.
Bug: v8:12578
Change-Id: I5b6f30b97c2db895183216ae5d5dbd4e5fa9d0c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3676855
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80814}
... when external code space is enabled.
Since we are using near jump/call instruction only for [tail]calling
builtins, we can increase the code range as long as we can guarantee
that the remapped builtins are always reachable. We can do that by
remapping embedded builtins into the middle of the code range.
Bug: v8:11880, v8:12689
Change-Id: I69901634586df3c35618ea7bd5311102e4675f6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669107
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80810}
Mostly in comments, again, not much to be said...
Bug: v8:12425
Change-Id: I75b4b244e6fa259a29f6cf28bd8258b035af4be6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3673536
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80808}
Similar to https://crrev.com/c/3634781, this switches some {BitVector}s
in the regular top-tier register allocator to {SparseBitVector}. For
functions with a huge amount of virtual registers, this would save a
significant amount of memory, and also performance.
For small number of registers though we probably introduce a slight
regression, because there is one more dynamic check to be performed
before accessing the bits.
R=mslekova@chromium.org
Bug: chromium:1313379, v8:12780
Change-Id: Ib65d22ad0a8e2c933f7178f4fefc36e500be623c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650602
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80806}
