Let StressConcurrentAllocatorTask allocate small, medium and large
objects to test different code paths.
Bug: v8:10315
Change-Id: Ifff7e91bc95f0d926a58321b481183e9acf8bd32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335182
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69217}
This is a reland of b354e344fd
This CL adds 3 fixes:
* Unprotect code object before creating filler
* Allows AllocationObserver::Step to add more AllocationObservers
* Update limit in NewSpace::UpdateLinearAllocationArea
Original change's description:
> [heap] Refactor allocation observer in AllocationCounter
>
> Moves accounting of allocation observers into the AllocationCounter
> class. This CL removes top_on_previous_step_ for counters that are
> increased regularly in the slow path of the allocation functions.
>
> AdvanceAllocationObservers() informs the AllocationCounter about
> allocated bytes, InvokeAllocationObservers() needs to be invoked when
> an allocation step is reached. NextBytes() returns the number of bytes
> until the next AllocationObserver::Step needs to run.
>
> Bug: v8:10315
> Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69170}
Bug: v8:10315
Change-Id: I89ab4d5069a234a293471f613dab16b47d8fff89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332805
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69216}
A minor refactoring to the logic for triggering callbacks:
1. If compilation failed, do only trigger the kFailedCompilation event.
2. Use the TriggerCallbacks method also for triggering the
kFailedCompilation event.
R=thibaudm@chromium.org
Bug: chromium:1101340
Change-Id: I3446d708d28068448e6eca3e637c9af673f5311d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332171
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69215}
In preparation for adding new NCI (and TP) code kinds.
- Free the unused bit in Code::flags.
- Be more precise about the flag field sizes (int32 instead of int).
- Add and refactor related static asserts.
Bug: v8:8888
Change-Id: Ice0d4df9de528de77dfb5c04279cfdc4b030efc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328788
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69213}
The DevTools front-end uses so-called Wasm evaluator modules to get to
the values of variables in scope when the wasmDWARFDebugging experiment
is turned on. We rely on the `Debugger.executeWasmEvaluator()` method in
the Chrome DevTools Protocol (CDP) to accomplish this, which in turn is
controlled by this global flag.
Since we intend to gather more feedback from selected internal /
external teams on the DWARF debugging experience, we need to ship this
flag by default to make it easier to test the new experiment without
having to fiddle with additional flags to pass to Chrome on the command
line (and asking folks whether they really started Chrome correctly).
Bug: chromium:1041362
Change-Id: I1e170383fa7a34c41eec8c4867c38b7d8e871e8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335072
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69212}
I tripped over this str/bytes issue as part of bringing up the
Chromium build under Python3.
Bug: chromium:1112471
Change-Id: I723c7d9df8bcac24c160c549a03dcbd34c1d92f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334222
Commit-Queue: Dirk Pranke <dpranke@google.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69210}
x64's implementation of i64x2.shr_s was overwriting the scratch
register. kScratchRegister is used to hold the extracted lane of the
SIMD register, but in certain cases [0], is also used to back up the
value of rcx. When this happens, the supposed backed-up rcx was
overwritten (definitely) by each extract lane, so we end up restoring
an incorrect value of rcx, leading to an eventual crash in certain
benchmarks, when this extracted lane was used as a memory operand (see
linked bugs).
[0] when register holding the shift value is not rcx, which sarq_cl
relies on
Bug: v8:10752
Bug: chromium:1111522
Change-Id: Iaf3264e16f94e78bad4290783757f0b722d40411
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334354
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69208}
This is a stop-gap solution (while we wait for a proper spec)
that lets managed WasmGC objects perform round-trips through
JavaScript. On the JavaScript side, they appear as empty/opaque.
Bug: v8:7748
Change-Id: I0dd368bc14d622f3ef41871484228267359e9b5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316306
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69207}
After allocating a new code space, we do some initial allocations in the
new space (e.g. for the jump table). These allocations are not allowed
to fail.
If this in indeed what's happening in the linked bug, this CHECK will
give fuzzers a chance to find us a reproducer.
Drive-by: Introduce {WasmCodeAllocator::kUnrestrictedRegion} to remove
magic constants.
R=ahaas@chromium.org
Bug: v8:1111266
Change-Id: Ia76721653226bd4aa346b89ffab0c80f67892794
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333250
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69204}
If we cancel the task in the thread where it's supposed to run,
task cancelling will always succeed.
This simplifies the logic.
Bug: v8:10239
Change-Id: I3fb5c93a49c52d958aa947d693700161bc18eee5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332807
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69203}
The majority of the content is the Atomics.waitAsync implementation
which I wrote.
"git blame" shows I've touched 123 / 274 lines in futex-emulation.h and
551 / 875 lines in futex-emulation.cc.
(Status before https://chromium-review.googlesource.com/c/v8/v8/+/2319989 which was moving
code around.)
No-Try: True
Change-Id: Ib31dc0bb778aed90d5c4c56ccb0e556655ce6946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332813
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69202}
... since it's still a valid index.
Change-Id: I498ff27898cefa5df752ac0ad73408ce76ac06c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327911
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69200}
Adds support for non-simple fp aliasing (e.g., Arm) for the fast
register allocator.
BUG=v8:9684
Change-Id: I6717ef1c6cb4e585fa4b6ea8cea7087e68f441e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300483
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69198}
Allow the allocation of large old space objects through
LocalHeap::AllocateRaw. OldLargeObjectSpace::AllocateRawBackground will
allocate a large object on the background thread.
Bug: v8:10315
Change-Id: I9212f0c6770855dbe33490516aae7056987e192d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332804
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69195}
LocalHeap::AllocateRaw will be similar to Heap::AllocateRaw and
handle all allocations. LocalHeap::AllocateRawOrFail will perform a GC
and afterwards retry the allocation in a loop.
Bug: v8:10315
Change-Id: I68468962cf9102697aa547b2aa05c7ec6bafd19e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332801
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69193}
Bug: v8:7790
Change-Id: Ie296b0bcc6c3b26be5ad54f4558a75250a2f2157
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332232
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69191}
Chrome is currently adding a 128-bit V8ContextToken to keep track of
V8 contexts across multiple isolates and processes. Having per-isolate
token exposed by V8 leads to confusion of these two tokens.
This moves v8::Context::Token to v8::metrics::Recorder and changes
the corresponding functions:
- v8::Context::GetToken => v8::metrics::Recorder::GetContextId
- v8::Context::GetByToken => v8::metrics::Recorder::GetContext
This CL is purely mechanical and does not change the behaviour.
Bug: chromium:1101749
Tbr: clemensb@chromium.org
Change-Id: I31bbfa02ebab1c0d91b00f0d08c1b236392d14d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330023
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69188}
This reverts commit b354e344fd.
Reason for revert: Clusterfuzz found issues with this CL.
Original change's description:
> [heap] Refactor allocation observer in AllocationCounter
>
> Moves accounting of allocation observers into the AllocationCounter
> class. This CL removes top_on_previous_step_ for counters that are
> increased regularly in the slow path of the allocation functions.
>
> AdvanceAllocationObservers() informs the AllocationCounter about
> allocated bytes, InvokeAllocationObservers() needs to be invoked when
> an allocation step is reached. NextBytes() returns the number of bytes
> until the next AllocationObserver::Step needs to run.
>
> Bug: v8:10315
> Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69170}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: Icd713207bfb2085421fd82009be24a0211ae86da
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332667
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69187}
Rolling v8/build: f0fc706..65e3fac
Rolling v8/buildtools: 9e12121..42e9461
Rolling v8/third_party/aemu-linux-x64: nz3cLclK4lWm6gzvGCOHPQAKJUO8EsMBr7EIUXwS9SEC..TfK3Whl6AfZifLOotcOS_jvckKztERlPvmVyZo16fN0C
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d292e89..2cd291a
Rolling v8/third_party/depot_tools: a58287b..98b332f
Rolling v8/third_party/zlib: 103247f..a21a4e8
Rolling v8/tools/clang: 2eaa59d..fd3758aTBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I218e41dfe1026a7851ed4e0a3ac7fbe924f4f9cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333174
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#69184}
Also add some simple unittests for these functions.
Bug: v8:10696
Change-Id: Ic7607780b4eaf275b20d0937bf214846bf51d539
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330806
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69183}
Adds support for tracking register allocations across basic block
boundaries to the fast register allocator. For now we still spill
on loop headers, and spill when merging register states if the
register state isn't exactly the same.
BUG=v8:9684
Change-Id: I2aaf992fe8b0a5c698b1e44526951c63aedbe86c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300480
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69181}
Some of these functions will be reused by Liftoff. Move them into
simd-shuffle for sharing (even though these only apply to ia32 and x64).
Bug: v8:10696
Change-Id: Ib83a2fcd443f93f86d7a4c85898205edb8c3925c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330796
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69180}
If incoming map is deprecated, generate code to migrate the map. Since
this involves generating additional code and a call to runtime, we only
do this if one of the receiver maps was a migration target when
optimizing this function. If not, we deoptimize and discard the
optimized code if we see a deprecated map. This is to avoid bailout
loops when we see deprecated maps.
This change does the following:
// We generated code to migrate deprecated maps only if one of the maps
// in feedback vector is a migration target.
if ( there are migration targets in feedback)
{
if (checkMaps fails) {
if (incoming map is deprecated) {
migrate the map
checkMaps with the new map
} else {
bailout
}
}
} else {
if (checkMaps fails)
bailout;
}
Bug: v8:10582, v8:9684
Change-Id: I8a04c77ed209dd2fb0300a783d844f2335a678c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292231
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69179}
Two of them were in comments; updated them to V8_OS_MACOSX.
Two of them were incorrectly in #if statements. Updated them to
V8_OS_MACOSX.
Bug: chromium:823915, chromium:1105907
Change-Id: Ibfc0f8936dbc8cbf3b05a674e882bbc480d0b4c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2331736
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69178}
This allows templates to preserve the type of implicit parameters to
select a better ovleroad, without generally extending overload
resolution to implicit parameters, which could be confusing.
Bug: v8:7793
Change-Id: Ie57090a295b0b46d03789829b975fc16e2a9c5b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2329630
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69177}
As a note, we are not yet passing this to the background so we only
have canonical persistent handles on the main thread.
Bug: v8:7790
Change-Id: I15b264cfacc2d5524a3d13f62574a3576bb7e1a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330017
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69176}
This allows the configuration v8_enable_shared_ro_heap and
v8_enable_pointer_compression on Linux and Android, although it still
defaults to off.
When pointer compression and read-only heap sharing are enabled, sharing
is achieved by allocating ReadOnlyPages in shared memory that are
retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are
then remapped into the address space of the Isolate ultimately using
mremap.
To simplify the creation process the ReadOnlySpace memory for the first
Isolate is created as before without any sharing. It is only when the
ReadOnlySpace memory has been finalized that the shared memory is
allocated and has its contents copied into it. The original memory is
then released (with PC this means it's just released back to the
BoundedPageAllocator) and immediately re-allocated as a shared mapping.
Because we would like to make v8_enable_shared_ro_heap default to true
at some point but can't make this conditional on the value returned by
a method in the code we are yet to compile, the code required for
sharing has been mostly changed to use ifs with
ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where
a compile error would result due to the absence of a class members
without sharing. IsReadOnlySpaceShared() will evaluate
CanAllocateSharedPages in the platform PageAllocator (with pointer
compression and sharing enabled) once and cache that value so sharing
cannot be toggled during the lifetime of the process.
Bug: v8:10454
Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69174}
When we are not going to be accessing the heap anymore, we can park the
LocalHeap which signals to not wait for this thread when requesting
safepoints.
There are a couple of places where we want to explicitly allow access
to the heap, even though we have previously parked. We use
UnparkedScope for those cases.
Bug: v8:7790
Change-Id: Ic0acc51fe02af89836226670b828db4aafba4d0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319993
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69173}
We only use IsParked from the thread that owns the LocalHeap, which is
the only thread which mutates state_. So it is safe to read state_ from
that thread without a mutex.
Bug: v8:10315
Change-Id: I3725ca4c4c4da1c661d7b4f06d295312914b4b52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332168
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69172}
Moves accounting of allocation observers into the AllocationCounter
class. This CL removes top_on_previous_step_ for counters that are
increased regularly in the slow path of the allocation functions.
AdvanceAllocationObservers() informs the AllocationCounter about
allocated bytes, InvokeAllocationObservers() needs to be invoked when
an allocation step is reached. NextBytes() returns the number of bytes
until the next AllocationObserver::Step needs to run.
Bug: v8:10315
Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69170}
