This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.
LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).
This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.
Bug: chromium:1011762
Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
This reached consensus in the March 2020 TC39.
https://github.com/tc39/ecma262/pull/1908
This aligns JS with wasm, which allows atomics operations on non-shared
linear memory.
Bug: v8:10687, v8:9921
Change-Id: I7b60473b271cee6bccb342e97a4fd3781aedddb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330802
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69392}
This fixes a case where we hit a DCHECK in Debug mode, or silently
discarded bogus data in Release mode without rejecting the module.
Fixed: chromium:1108815
Change-Id: I928ff244a54b016cd8470be1ec4b5faf2c7e3994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349768
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69391}
Remove allocation_mutex_ and use the already existing space_mutex
to protect the free list from concurrent allocation.
Bug: v8:10315
Change-Id: I8d823bcb80dfa49c6431a6db875488bc8d6ee8b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352783
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69384}
Rather than an Object array, use a Tagged_t array to store the
elements of the off-heap string table. This matches the old on-heap
string table's behaviour, and recovers memory regressions from that
work.
To be able to do this, this also introduces a new slot type,
OffHeapObjectSlot. This is because CompressedObjectSlot assumes that
the slot is on-heap, and that it can mask the slot location to
recover the isolate root. OffHeapObjectSlot doesn't define an
operator*, and instead provides a `load(const Isolate*)` method.
The other slots also gain this method so that they can use it in
slot-templated functions. Also, the RootVisitor gains an
OffHeapObjectSlot overload, which is UNREACHABLE by default and only
needs to be defined by visitors that can access the string table.
As a drive-by, fix some non-atomic accesses to the off-heap string
table, also using the new slot.
Bug: chromium:1109553
Bug: chromium:1115116
Bug: chromium:1115559
Bug: chromium:1115683
Change-Id: I819ed7bf820e9ef98ad5d5f9d0d592efbb6f5aa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352489
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@{#69381}
Cleanups:
* Additional offset was always 0 so it can be removed
* Reordered arguements to take advantage of the implicit arguments
Bug: v8:9708, v8:6949
Change-Id: I2168b80013958ab5b017280422fbfc9c7a137dcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349304
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69380}
This extends the skip list feature from step over to step into.
On a step into we can pass a skipList, which contains locations
that we do not want to stop at.
Bug: chromium:1105765
Change-Id: I70a4ded3f6a7eada14f54ae9c2f994c155c7305b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345224
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69376}
While waiting for baseline compilation to finish (i.e. in the
synchronous compilation API), do also contribute to compilation. This
restores the performance from before switching to the jobs API, because
all threads will now be used for synchronous compilation.
Drive-by: Remove unused {CompilationStateImpl::background_compile_token}
method.
R=ahaas@chromium.org
Bug: chromium:1101340, chromium:1113234
Change-Id: I61eddb813eb2779cdd41f11c8d840d63132d4360
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351671
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69373}
Instead of hard-coding the logic for empty modules, just re-use the
{TriggerCallbacks} method. This will also ensure that the
{finished_events_} set will be populated correctly, such that callbacks
added later will still receive the events.
R=ahaas@chromium.org
Bug: chromium:1101340
Change-Id: I6641f23dc0459d0b6591bb03cc8c1b99dcaa90ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351669
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69368}
Since it will be patched in later in the cases where it will be used,
there is no need to have it as a parameter.
Bug: v8:7790
Change-Id: I93b27f3baf8c3841a60f5ac5ed09993d1caf19bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351667
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69366}
This reverts commit 1b35c0fa15.
Reason for revert: Seems to reliably break a numerics test:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31516
Original change's description:
> Improve NumberToString when cache miss and Smi
>
> Cache miss was handled in runtime before. This change add fast path for
> Smi in this case.
>
> Perf show 30% improvement for the following example.
> Before 67 ms
> After 42 ms
>
> const start = new Date();
> const MAX = 1000000;
> for (var i = 0; i < MAX; i++) {
> i.toString();
> }
> const end = new Date();
> console.log("Time :"+ (end-start));
>
> Change-Id: I162e9c35f58551ca6a5a0efe79fb7c7b482a8594
> Bug: v8:10477
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332866
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69362}
TBR=jgruber@chromium.org,leszeks@chromium.org,duongn@microsoft.com
Change-Id: I80f6bdb0464c0034e6c4a16478848618cef7e046
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10477
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351389
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69365}
Fix containing() w/ n point to surrogate tail.
Bug: v8:6891
Change-Id: I4d7e4083ba409eecaefaf2ec5c67b7226bd7c97c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348208
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69363}
Cache miss was handled in runtime before. This change add fast path for
Smi in this case.
Perf show 30% improvement for the following example.
Before 67 ms
After 42 ms
const start = new Date();
const MAX = 1000000;
for (var i = 0; i < MAX; i++) {
i.toString();
}
const end = new Date();
console.log("Time :"+ (end-start));
Change-Id: I162e9c35f58551ca6a5a0efe79fb7c7b482a8594
Bug: v8:10477
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332866
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69362}
The (now unique)PersistentHandles container follows this path:
1) PersistentHandles created via PersistentHandlesScope inside of
CompilationHandleScope
2) Owned by OptimizedCompilationInfo
3) Owned by JSHeapBroker
4) Owned by the broker's LocalHeap
5) Back to the broker for a brief moment (after tearing down the
LocalHeap as part of exiting LocalHeapScope)
6) Back to OptimizedCompilationInfo when exiting the LocalHeapScope.
There is a special case in GenerateCodeForTesting where the JSHeapBroker
will not be retired in that same method. In this case, we need to
re-attach the PersistentHandles container to the JSHeapBroker.
The identity map of the persistent & canonical handles also gets passed
around like the persistent handles. The only difference is that is
created in the CanonicalHandleScope (i.e step 1) is different).
Bug: v8:7790
Change-Id: I2da77a7e08f3fd360a46b606c5fbda08c0af27df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332811
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69360}
Remove extra source positions added by Liftoff to help with OSR. Compute
the return address based on the call source position instead.
R=clemensb@chromium.org
Bug: v8:10337
Change-Id: Ifc14e924825b670ebaed920bb19d0fa09eca1b23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351666
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69359}
FeedbackSlotIterator abstracts over the different IC states and
provides an unified interface to iterate over the map and handlers in
the IC.
Bug: v8:10582
Change-Id: I67861bfbd33d82e8b1ad06156fbf6fd72775321c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349295
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69357}
Move external memory counters out of IsolateData back into Heap.
The class ExternalMemoryAccounting now stores all counters and is
responsible for updates. This change will allow turning counters into
atomic variables.
Bug: v8:10315
Change-Id: I2abeda298d3cfcc630fd04ca78a3d6d703e3b419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346647
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69356}
DebugInfo::RemoveBreakpoint was never called. Call it in
WasmScript::ClearBreakPoint to remove the breakpoint from the list and
recompile the function.
R=clemensb@chromium.org
Bug: v8:10147
Change-Id: I0d11bdab102eeacc2a5f9ae9b4a20e8c900b26f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351665
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69355}
The only user was ArrayBufferTracker which got removed already.
Bug: v8:10064
Change-Id: I97f8ed0727abec01b3b65ba965026f61fb9acb85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346406
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69354}
Since the StringTable can only contain old strings, skip iterating it
when SkipRoot::kOldGeneration is set.
Bug: chromium:1115132, chromium:1115100
Change-Id: I6d065a0ea7f3142c5d474eb0919e801e13976f6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351664
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69353}
ArrayBufferTracker was superseded by ArrayBufferList and
ArrayBufferSweeper. Now that ArrayBufferSweeper is used in production,
we can remove the unused ArrayBufferTracker mechanism.
Bug: v8:10064
Change-Id: I479169c76b6c5c634672024f77e689bb64a36504
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69351}
This reverts commit f4548e7598.
Reason for revert: Breaks some gap resolver tests:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/24204
Original change's description:
> [regalloc] Place spill instructions optimally
>
> Design doc:
> https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
>
> Most of this change follows directly what is discussed in the design
> document. A few other things are also changed:
>
> - PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
> that it can make use of the decision regarding whether a value is
> spilled at its definition or later.
> - SpillSlotLocator is removed. It was already somewhat confusing,
> because the responsibility for marking blocks as needing frames was
> split: in some cases they were marked by SpillSlotLocator, and in
> other cases they were marked by CommitSpillsInDeferredBlocks. With
> this change, that split responsibility would become yet more
> confusing if we kept SpillSlotLocator for the values that are spilled
> at their definition, so I propose a simpler rule that whatever code
> adds the spill move also marks the block.
> - A few class definitions (LiveRangeBound, FindResult,
> LiveRangeBoundArray, and LiveRangeFinder) are moved without
> modification from register-allocator.cc to register-allocator.h so
> that we can refer to them from another cc file.
>
> Bug: v8:10606
> Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69345}
TBR=rmcilroy@chromium.org,seth.brenith@microsoft.com,thibaudm@chromium.org
Change-Id: Ie57109a009ee7ee541a6ff6f89901d1ac99027d2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2350440
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69347}
This is a reland of 57242a051e
no-sse4.1 builds were failing due to missing simd-scalar-lowering
for s128.const, this reland adds that implementation.
Original change's description:
> [wasm-simd][arm] Use vmov to move all ones to register
>
> vceq(dst, dst, dst) does not seem to always set the register to all
> ones. The right way should be be to use vmov (immediate) anyway. This
> was not supported in the assembler yet, so we need changes to the
> assembler, diassembler, and simulator.
>
> There is an unfortunate fork in logic in the simulator, due to the way
> the switches are set up, vmov (imm) logic is duplicated across two
> different cases, because the switch looks at the top bit of the
> immediate. Refactoring this will be a bigger change that is irrelevant
> for this bug, so I'm putting that off for now. Instead we extract the
> core of vmov (imm) into helpers and call it in the two cases.
>
> Bug: chromium:1112124
> Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69315}
Bug: chromium:1112124
Change-Id: Id450e5cea41f7a569e49be8386a7788ca8f00658
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346937
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69346}
Design doc:
https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
Most of this change follows directly what is discussed in the design
document. A few other things are also changed:
- PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
that it can make use of the decision regarding whether a value is
spilled at its definition or later.
- SpillSlotLocator is removed. It was already somewhat confusing,
because the responsibility for marking blocks as needing frames was
split: in some cases they were marked by SpillSlotLocator, and in
other cases they were marked by CommitSpillsInDeferredBlocks. With
this change, that split responsibility would become yet more
confusing if we kept SpillSlotLocator for the values that are spilled
at their definition, so I propose a simpler rule that whatever code
adds the spill move also marks the block.
- A few class definitions (LiveRangeBound, FindResult,
LiveRangeBoundArray, and LiveRangeFinder) are moved without
modification from register-allocator.cc to register-allocator.h so
that we can refer to them from another cc file.
Bug: v8:10606
Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69345}
I noticed a pattern that has been copied around to various places and
thought a helper function might be appropriate.
Change-Id: I8944ac5166c649f15c09f587308406cab317b8d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346766
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69344}
This reverts commit 0ba115e6a9.
Reason for revert: Breaks test on TSAN - block-conflicts
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/14230
Original change's description:
> Reland^2 "[flags] warn about contradictory flags"
>
> This is a reland of d8f8a7e210
> Change compared to last reland:
> - Do not check for d8 flag contradictions in the presence of --fuzzing
> - Allow identical re-declaration of --cache=*
>
> Original change's description:
> > Reland "[flags] warn about contradictory flags"
> >
> > This is a reland of b8f9166664
> > Difference to previous CL: Additional functionality to specify
> > incompatible flags based on GN variables and extra-flags, used
> > to fix the issues that came up on the waterfall.
> >
> > This also changes the rules regarding repeated flags: While
> > explicitly repeated flags are allowed for boolean values as long
> > as they are identical, repeated flags or explicit flags in the
> > presence of an active implication are disallowed for non-boolean
> > flags. The latter simplifies specifying conflict rules in
> > variants.py. Otherwise a rule like
> >
> > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > "--gc-interval=*": ["--gc-interval=*"],
> > }
> >
> > wouldn't work because specifying the same GC interval twice
> > wouldn't actually count as a conflict. This was an issue with
> > test/mjsunit/wasm/gc-buffer.js, which specifies
> > --gc-interval=500 exactly like the extra flag by the stress bot.
> >
> > Also, this now expands contradictory flags checking to d8 flags
> > for consistency.
> >
> > Original change's description:
> > > [flags] warn about contradictory flags
> > >
> > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > >
> > > Bug: v8:10577
> > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68168}
> >
> > Bug: v8:10577
> > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68989}
>
> Bug: v8:10577
> Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69339}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I1454a05e357ddd704db7fb79e51be65d45a9a16e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348365
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69341}
This is a reland of d8f8a7e210
Change compared to last reland:
- Do not check for d8 flag contradictions in the presence of --fuzzing
- Allow identical re-declaration of --cache=*
Original change's description:
> Reland "[flags] warn about contradictory flags"
>
> This is a reland of b8f9166664
> Difference to previous CL: Additional functionality to specify
> incompatible flags based on GN variables and extra-flags, used
> to fix the issues that came up on the waterfall.
>
> This also changes the rules regarding repeated flags: While
> explicitly repeated flags are allowed for boolean values as long
> as they are identical, repeated flags or explicit flags in the
> presence of an active implication are disallowed for non-boolean
> flags. The latter simplifies specifying conflict rules in
> variants.py. Otherwise a rule like
>
> INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> "--gc-interval=*": ["--gc-interval=*"],
> }
>
> wouldn't work because specifying the same GC interval twice
> wouldn't actually count as a conflict. This was an issue with
> test/mjsunit/wasm/gc-buffer.js, which specifies
> --gc-interval=500 exactly like the extra flag by the stress bot.
>
> Also, this now expands contradictory flags checking to d8 flags
> for consistency.
>
> Original change's description:
> > [flags] warn about contradictory flags
> >
> > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> >
> > Bug: v8:10577
> > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68168}
>
> Bug: v8:10577
> Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68989}
Bug: v8:10577
Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69339}
We shouldn't spill weak pointers onto the stack when calling functions
that can trigger GC. DynamicMapChecks operator was using feedback loaded
from the feedback vector across the TryMigrateInstance function call.
The feedback can be a weak pointer to receiver map for monomorphic cases
and TryMigrateInstance can trigger a GC. This cl fixes it by holding
a holding a strong reference to the feedback.
Bug: v8:10774,v8:10582,v8:9684
Change-Id: Ia36f4d8ad46421ae570f41439bc1f0875081deee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336804
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69338}
This is a reland of 60ee70bb40.
The wasm c-api flakes were fixed in https://crrev.com/c/2349293.
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
Bug: v8:10777
Change-Id: I2a7c1429812ca46d88a2902b8e0a7b7e3d638b56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349290
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69335}
Now that background threads participate in sweeping, this method
races because multiple threads now want to update that counter. We could
either make this counter atomic or remove it entirely. This CL removes
this counter since it isn't strictly necessary, it is only used when
sweeper finds more garbage than markers. This happens e.g. with
right-trimming but should be rare and is eventually fixed in the next
GC.
Bug: v8:10315
Change-Id: Iebae8937860160a3b49bedd03c2e21e41f7dfe76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349296
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69334}
We only want to serialize TurboFan code, because Liftoff code could
contain breakpoints, and we start thinking about embedding other
non-relocatable constants.
Thus, wait until top-tier compilation finished before triggering
serialization.
A follow-up CL will make serialization fail if any Liftoff code is
encountered.
R=ahaas@chromium.org
Bug: v8:10777
Change-Id: I73d6c2d868545fcd4069a8cf9850ca7fca375ecb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349293
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69332}
This removes the {InterpretWasmModuleForTesting} function in favor of
{InterpretWasmModule}, and uses that in {InterpretAndExecuteModule}.
The latter again is reused in {WasmExecutionFuzzer::FuzzWasmModule},
such that all fuzzers execute the same checks now.
R=ahaas@chromium.org
Bug: chromium:1112099, chromium:1113681
Change-Id: Ia8818b93e9274266a81573edd6852e4e4734b150
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346283
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69331}
This is the first step in refactoring Worklist to allow arbitrary
number of local worklists with private segments:
- Introduce MarkingWorklistImpl<> which will eventually replace
(and will be renamed to) Worklist.
- MarkingWorklistImpl<> owns the global pool of segments but does not
keep track of private segments.
- MarkingWorklistImpl<>::Local owns private segments and can be
constructed dynamically on background threads.
- Rename the existing MarkingWorklistsHolder to MarkingWorklists.
- Rename the existing MarkingWorklists to MarkingWorklists::Local.
- Rename the existing marking_workists_holder to marking_worklists.
- Rename the existing marking_worklists to local_marking_worklists.
Design doc: https://bit.ly/2XMtjLi
Bug: v8:10315
Change-Id: I9da34883ad34f4572fccd40c51e51eaf50c617bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2343330
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69330}
This change adds support for skipping locations that are in a skipList
on step over. This feature is useful for when we are debugging
C++ applications that have DWARF information we only want to stop on
every breakable location in C++, not non every breakable location
on wasm level.
Bug: chromium:1105765
Change-Id: Ie835b011a00cf31e0c5b2df1ac96ebd89f53d23a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339458
Reviewed-by: Eric Leese <leese@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69329}
This CL adds more systematic predicates to JSFunction to reason about
available code kinds. Introduced terminology:
- Attached code kinds are accessible directly from the JSFunction
itself.
- Available code kinds are either attached or accessible indirectly.
- The Active code kind is the one that would be executed on the next
function execution.
Bug: v8:8888
Change-Id: I9468884dfe97a6cb73f8329b2b6cb62b622d3e7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345966
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69325}
32-bit MSVC generates a C4018 warning for signed/unsigned mismatch.
Fix this by casting the std::numeric_limits<int32_t>::max() return
value.
Change-Id: Iaff6b81c797a88654a7d2fa6d910da105d824df8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346934
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69321}
The design included per-location lists, but they were left out in
Version 1 of the implementation.
In addition: drive-by style unification.
Bug: v8:10239
Change-Id: Ia4d69fdf4ce0c3aad2dae8082e00e9fa14c4170a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339620
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69319}
The hight 32 bits of the result of mulhw are undefined and need
to be cleared manually.
Change-Id: I0e746898aa26a7970ab59b89c374afd1377028ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2347208
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69318}
This reverts commit 57242a051e.
Reason for revert: regression tests fails:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31477
Original change's description:
> [wasm-simd][arm] Use vmov to move all ones to register
>
> vceq(dst, dst, dst) does not seem to always set the register to all
> ones. The right way should be be to use vmov (immediate) anyway. This
> was not supported in the assembler yet, so we need changes to the
> assembler, diassembler, and simulator.
>
> There is an unfortunate fork in logic in the simulator, due to the way
> the switches are set up, vmov (imm) logic is duplicated across two
> different cases, because the switch looks at the top bit of the
> immediate. Refactoring this will be a bigger change that is irrelevant
> for this bug, so I'm putting that off for now. Instead we extract the
> core of vmov (imm) into helpers and call it in the two cases.
>
> Bug: chromium:1112124
> Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69315}
TBR=bbudge@chromium.org,jkummerow@chromium.org,v8-arm-ports@googlegroups.com,zhin@chromium.org
Change-Id: I5d9d1dcb81771f71001d959ec5a03a43a11c4233
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1112124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2347211
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69316}
vceq(dst, dst, dst) does not seem to always set the register to all
ones. The right way should be be to use vmov (immediate) anyway. This
was not supported in the assembler yet, so we need changes to the
assembler, diassembler, and simulator.
There is an unfortunate fork in logic in the simulator, due to the way
the switches are set up, vmov (imm) logic is duplicated across two
different cases, because the switch looks at the top bit of the
immediate. Refactoring this will be a bigger change that is irrelevant
for this bug, so I'm putting that off for now. Instead we extract the
core of vmov (imm) into helpers and call it in the two cases.
Bug: chromium:1112124
Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69315}
Optimize shuffles which only use a single operand (called swizzles),
after canonicalization.
Bug: v8:10696
Change-Id: I2e5ffdb723123dffb0abcb6126345972ddc9f652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335735
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69313}
With a displacement of int32_t min (-2^31), and a displacement mode of
kNegativeDisplacement, we will try to negate this constant, but the
result will not fit in an int32_t, leading to a runtime crash.
Check for this special case in CanBeImmediate, and return false.
Bug: chromium:1091892
Change-Id: I7f18153d13805f2836dd5c8e1bc098f1e9600566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2341095
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69311}
Add missing source position for stack check, used by OSR to find the
correct return address.
R=clemensb@chromium.org
Bug: v8:10235
Change-Id: Ie26dd3b2079168e846f84b3a4ffe18b838649be7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339625
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69309}
* CopyElementsOnWrite
* CopyFixedArrayElements
* GrowElementsCapacity
There are two versions of CopyFixedArrayElements which still remain to
be TNodified and removed ParameterMode.
Bug: v8:9708, v8:6949
Change-Id: I0d63b51004aefbc55dfc57184ed9a0dda7c9b526
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339478
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69306}
A new field for signature type was added to WasmExportedFunctionData.
It is set to 0 or 1 depending on the parameter count.
(It's set and being used only in 0 and 1 parameter cases.)
Added new JS tests for 1 parameter wasm functions.
Bug: v8:10701
Change-Id: I349d881a2860f1a50b91e08d0126ca71c5f6483b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339622
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69302}
New space size needs to be adjusted during global safepoint.
Bug: v8:10315
Change-Id: I670024faa55ce68a4091af6f358f45d20c66fa0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239573
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69301}
Previously, all ThisExpression's had kNoSourcePositions leading to
incorrect error messages like this:
➜ d8 -e "function t() { for (const x of this) {} } t();"
unnamed:1: TypeError: undefined is not a function
function t() { for (const x of this) {} } t();
^
TypeError: undefined is not a function
at t (unnamed:1:11)
at unnamed:1:43
This patch allows creation of a ThisExpression with a source position,
leading to a better error message:
➜ d8 -e "function t() { for (const x of this) {} } t();"
unnamed:1: TypeError: this is not iterable
function t() { for (const x of this) {} } t();
^
TypeError: this is not iterable
at t (unnamed:1:32)
at unnamed:1:43
This patch does not remove the existing cached version of
ThisExpression and instead creates a new one when required.
Bug: v8:6513
Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69300}
Up until now. we only checked the size of tables defined in a module
at instantiation time. For imported tables we only checked if the
imported table matched the declared import in size. This causes a
problem because we allocate function tables also for imported tabled
before we actually look at the imported table.
With this CL we first check the size of all tables, and only then start
to initialize and load them.
R=jkummerow@chromium.org
Bug: chromium:1114006
Change-Id: Iaf194ed21fb83304fe3a7f0f7ba7b282396e3954
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339473
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69291}
Forgetting to add a new bytecode into the lists in
serializer-in-background-compiler.cc results in a confusing CHECK
failure.
This moves the failure to a discoverable place.
Change-Id: I3e78b4702bfa724748ec8ed3f7f49e0eedc504fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324246
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69290}
The cast from uint32_t to int caused an integer overflow that let a
bounds check succeed that should have failed.
R=jkummerow@chromium.org
Bug: chromium:1114005
Change-Id: Iea1af70af300be54c2a33d7dd10b3faa34d56eaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339472
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69289}
They're not valid, since the embedder is allowed to process
tasks in several threads, if they do it in a thread safe manner.
Bug: v8:10239
Change-Id: I6c397a8bba75ab7aec3ee8ea8de416af817d9514
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342846
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69285}
This reverts commit 60ee70bb40.
Reason for revert: wasm-api-tests/WasmCapiTest.Serialize starts flaking: https://crbug.com/v8/10784
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: Ic1349375bd562bb0a2724c39c27ef3247461c97b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342845
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69284}
This will ensure that the PersistentHandles are all created, and
in the OptimizedCompilationInfo before going into Exectute.
Bug: v8:7790
Change-Id: I1bc4f45153113c48422371498ff2cf79a1267737
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336803
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69280}
Now that we are using PersistentHandles, we don't need it anymore.
Bug: v8:7790
Change-Id: Id0b9d555191c00fb08dc2bb9099746076c5ad1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332161
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69278}
Spill registers before stack checks so that we can inspect them, similar
to traps.
OSR during a stack check is still unsupported and will be fixed in a
follow-up CL.
R=clemensb@chromium.org
Bug: v8:10235
Change-Id: I22c2da6b3f79b30c3838c568f9680204afc85d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339467
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69277}
We have the implicit assumption that Liftoff code will never be
serialized, and we start relying on that when implementing new features
(debugging, dynamic tiering).
This CL makes the serializer fail if the module contains any Liftoff
code. Existing tests are changed to ensure that we fully tiered up
before serializing a module (similar to the logic in Chromium).
The "wasm-clone-module" test needs to serialize the module before
enabling the debugger.
Note that chrome currently only serializes a module after it fully
tiered up, so that should be fine. If other embedders need the ability
to serialize a module in an arbitrary state, we will have to fix this
later. With this CL we will be on the safe side though and (gracefully)
fail serialization instead of accidentally serializing Liftoff code.
R=ahaas@chromium.org
Bug: v8:10777
Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69276}
This is a reland of 28ead05405
The failure is a test that is sensitive to adding a function
in a FunctionTemplate in d8: https://bugs.chromium.org/p/v8/issues/detail?id=10783
Original change's description:
> [Atomics.waitAsync] Fix removing multiple nodes when Isolate deinits
>
> RemoveNode already nullifies the next_ pointer of FutexWaitListNode,
> and DeleteAsyncNode was trying to retrieve it.
>
> Bug: v8:10239
> Change-Id: I595885de87f433d263eeacfc825a689efd467f5e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332812
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69259}
Bug: v8:10239
Tbr: leszeks@chromium.org
Change-Id: Icec590354886433a0b41c8f9b7af7101b54b7690
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339469
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69275}
Just a fast iteration over bytes written in Torque for Smi number and
non-decimal radix, also only for more than one string character result.
Improve following micro-benchmark by ~75%
Before
toHexString
toHexString-Numbers(Score): 7905000
After
toHexString
toHexString-Numbers(Score): 14419000
Bug: v8:10477
Change-Id: I366092d4d70156ad33830352c1122af8794bea76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330221
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69272}
Changes the isolate's string table into an off-heap structure. This
allows the string table to be resized without allocating on the V8 heap,
and potentially triggering a GC. This allows existing strings to be
inserted into the string table without requiring allocation.
This has two important benefits:
1) It allows the deserializer to insert strings directly into the
string table, rather than having to defer string insertion until
deserialization completes.
2) It simplifies the concurrent string table lookup to allow resizing
the table inside the write lock, therefore eliminating the race
where two concurrent lookups could both resize the table.
The off-heap string table has the following properties:
1) The general hashmap behaviour matches the HashTable, i.e. open
addressing, power-of-two sized, quadratic probing. This could, of
course, now be changed.
2) The empty and deleted sentinels are changed to Smi 0 and 1,
respectively, to make those comparisons a bit cheaper and not
require roots access.
3) When the HashTable is resized, the old elements array is kept
alive in a linked list of previous arrays, so that concurrent
lookups don't lose the data they're accessing. This linked list
is cleared by the GC, as then we know that all threads are in
a safepoint.
4) The GC treats the hash table entries as weak roots, and only walks
them for non-live reference clearing and for evacuation.
5) Since there is no longer a FixedArray to serialize for the startup
snapshot, there is now a custom serialization of the string table,
and the string table root is considered unserializable during weak
root iteration. As a bonus, the custom serialization is more
efficient, as it skips non-string entries.
As a drive-by, rename LookupStringExists_NoAllocate to
TryStringToIndexOrLookupExisting, to make it clearer that it returns
a non-string for the case when the string is an array index. As another
drive-by, extract StringSet into a separate header.
Bug: v8:10729
Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
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@{#69270}
There were a few places where we would do such verification even
without --verify-heap. The CL changes these to be in line with all
the rest.
Change-Id: Ia43708104c7d7818dc8d41d645a84f9b5e7446a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336796
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69269}
This is a revival of https://chromium-review.googlesource.com/c/v8/v8/+/2228332
The CL establishes the following:
*) Objects are marked before being pushed to the worklists.
*) Live bytes are always accounted after tracing an object (i.e. move
from Gray to Black below).
*) Previously not fully constructed objects are traced immediately
instead of pushed to the marking worklist.
This establishes the following invariants for all marking worklists:
1) White = !object.is_marked() && !worklist.contains(object)
2) Gray = object.is_marked() && worklist.contains(object)
3) Black = object.is_marked() && !worklist.contains(object)
Bug: chromium:1056170
Change-Id: I821573b3fbc057e6ffb836154271ff986ecb4d2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336797
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69268}
We used to check the size of tables at compile time, and threw a
CompilationError if a given size exceeded the implementation-defined
limit. However, the spec defines that an error should only be thrown
when the implementation-defined limit is reached, which is either at
instantiation time of during runtime at a table.grow.
With this CL the V8 implementation becomes spec compliant in this
regard.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69267}
Wasm recently switched from spawning a number of background tasks for
compilation to just using a single job (via the pretty new
{Platform::PostJob} API). This caused major regressions in several
benchmarks running in d8, because the {DefaultPlatform} is only using
half of the available worker threads for executing jobs with "user
visible" priority.
This CL changes this to use all available worker threads for "user
blocking" or "user visible" jobs, and two threads for "best effort"
jobs. The limit of two threads for best effort is identical to what
chromium does with best effort *tasks*. For user blocking and user
visible, chromium does not impose any limit, so we also remove the
limitation to half of the threads from d8.
Drive-by: Use {NewDefaultJobHandle} for constructing {DefaultJobHandle}.
R=mlippautz@chromium.orgCC=ahaas@chromium.org, gab@chromium.org, etiennep@chromium.org
Bug: chromium:1113234, chromium:1101340
Change-Id: I9280e649a1cf3832c562ff7251e8bda0103af111
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339481
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69265}
This is a reland of 408e7240d7
Change: Allow CSA load elimination accross code comments
Original change's description:
> [torque] typed context slot access
>
> This introduces a new type Slot<ContextType, SlotType> that is used
> for enum values used to access context slots.
> Together with new types for the various custom contexts used in
> Torque, this results in fairly type-safe access to context slots,
> including the NativeContext's slots.
>
> Drive-by changes:
> - Introduce a new header file to specify headers needed for
> generated CSA headers, to reduce the amount of includes specified
> in implementation-visitor.cc
> - Port AllocateSyntheticFunctionContext to Torque.
>
> Bug: v8:7793
> Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#69249}
Bug: v8:7793
Change-Id: I1fe100d8d62e8220524eddb8ecc4faa85219748d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339462
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69264}
In the --turbo-nci-as-highest-tier testing mode, allow NCI codegen for
OSR to increase coverage and simplify logic.
Bug: v8:8888
Change-Id: I254939928f92bf675dbf2b78cdd5b5dce802d972
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339460
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69262}
This reverts commit 1742d2561f.
Reason for revert: Longer safepoint can cause deadlocks with global handles.
Original change's description:
> [heap] Add safepoints in Heap GC methods
>
> Add safepoints to GC methods in Heap. There is still stuff in
> Heap::CollectGarbage which might work better or more precise in a global
> safepoint. Be conservative here and move everything into the safepoint,
> eventually we can start to move code out that is fine to run outside
> the safepoint.
>
> Bug: v8:10315
> Change-Id: I656dfd72f032eff6f386cec63a02777506650aa7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335192
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69228}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10315
Change-Id: Idaf575911b34674c16d46b41c2ebee9f56dbac6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339617
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69261}
The interpreter is not an execution tier in production any more. It's
only used in tests.
Thus, remove {ExecutionTier::kInterpreter} and instead add a
{TestExecutionTier} that still has {kInterpreter}.
If needed (in {TestingModuleBuilder::execution_tier()}), we translate
back from {TestExecutionTier} to {ExecutionTier} (for {kLiftoff} and
{kTurboFan} only).
The {TraceMemoryOperation} method, which is shared between interpreter
and production code, now receives a {base::Optional<ExecutionTier>}, and
we will just pass en empty optional if called from the interpreter.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: Ibe133b91e8dca6d6edbfaee5ffa0d7fe72ed6d64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335186
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69260}
`Object::GetRealNamedPropertyAttributes()` can crash if an empty
`Maybe` is returned by `JSReceiver::GetPropertyAttributes()` because
it was not checking for that. Fix that.
Refs: https://github.com/nodejs/node/issues/34606
Change-Id: Ic83f904ba7134786bcd8f786eb2ce98adb4fea1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335057
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69258}
This reverts commit 408e7240d7.
Reason for revert: debug builds fail
is_component_build = true
is_debug = true
use_goma = true
v8_enable_backtrace = true
v8_enable_debugging_features = true
v8_enable_fast_mksnapshot = true
v8_enable_slow_dchecks = true
v8_enable_snapshot_code_comments = true
v8_enable_verify_csa = true
v8_optimized_debug = false
v8_use_multi_snapshots = false
# Fatal error in ../../src/compiler/backend/instruction-selector.cc, line 3088
# Expected Turbofan static assert to hold, but got non-true input:
static_assert(nativeContext == LoadNativeContext(context)) at src/builtins/promise-resolve.tq:45:5
Original change's description:
> [torque] typed context slot access
>
> This introduces a new type Slot<ContextType, SlotType> that is used
> for enum values used to access context slots.
> Together with new types for the various custom contexts used in
> Torque, this results in fairly type-safe access to context slots,
> including the NativeContext's slots.
>
> Drive-by changes:
> - Introduce a new header file to specify headers needed for
> generated CSA headers, to reduce the amount of includes specified
> in implementation-visitor.cc
> - Port AllocateSyntheticFunctionContext to Torque.
>
> Bug: v8:7793
> Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#69249}
TBR=tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: I90c014022a808449aca4a9b9b3c3b8e036beb28e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340903
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69256}
Make sure that Torque/CSA generated phi's get kRepWord32 instead
of kRepWord8 or kRepWord16, since that's how we handle small
integer values in Turbofan.
Bug: v8:7793
Change-Id: I992b43287552b6117e90fbd0e11576470bc91509
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339096
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69253}
Change the heuristics for OSRing in TurboProp. Currently we OSR if
a funciton is already optimized / marked for optimization but is still
running optimized code. Since TurboProp optimizes much earlier than
TurboFan using the same heuristics would cause us to OSR more often
than required. This cl adds an additional check on the number of ticks
to make sure the function is hot enough for OSRing.
Bug: v8:9684
Change-Id: I7a1c8229182a928fd85efb23e2d385413c5209ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339098
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69252}
Just like the optimized code cache, the compiler should check the
isolate cache for NCI code objects and return them if they exist.
Drive-by: Skip additional tests to fix the nci_as_highest_tier test
variant. These are related to interactions with deoptimization, which
NCI code doesn't fully support yet.
Bug: v8:8888
Change-Id: I6253811f96993796cfc38fff0da7ffb4f1a5eb24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339095
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69251}
Changes:
- Remove restriction that function types cannot be used as ref types.
- Introduce WasmModule::has_type().
- Remove deferred signature checks in module-decoder. Instead, check if
type indices are out of bounds in consume_value_type (was bugged
before).
- Remove obsolete GetCanonicalRttIndex.
- Refine type of ref.func.
- Statically check immediate type against table type for call_indirect.
- Dynamic check for call_indirect should only happen when for funcref
(currently the only function supertype).
- Allocate a different map per function signature (with Map::Copy).
- Introduce function type equivalence and (trivial) subtyping.
- Add a few elementary tests.
Bug: v8:7748
Change-Id: If57d0bfd856c9eb3784191f3de423f53dfd26ef1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335190
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69250}
This introduces a new type Slot<ContextType, SlotType> that is used
for enum values used to access context slots.
Together with new types for the various custom contexts used in
Torque, this results in fairly type-safe access to context slots,
including the NativeContext's slots.
Drive-by changes:
- Introduce a new header file to specify headers needed for
generated CSA headers, to reduce the amount of includes specified
in implementation-visitor.cc
- Port AllocateSyntheticFunctionContext to Torque.
Bug: v8:7793
Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69249}
The surrounding code can trigger an allocation through InliningStack
which can eventually end up allocating a line ends array.
This is fine as-is because the existing iterator code makes a copy
of the byte array. It just triggers the no_gc dcheck in debug mode.
Fixed: v8:10778
Change-Id: Ic8c502767ec6c3d3b1f5e84df60638bd2fc6be75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339102
Auto-Submit: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69247}
This function was only used in a single test, and it tests a scenario
which cannot happen any more with the module cache: Having two copies of
the same NativeModule in an isolate.
Hence remove the respective runtime function and the test.
R=ahaas@chromium.org
Change-Id: Id7cdffbdf1bdf95a7eb31fdeb7d75b8e326bb90e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339100
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69246}
PagedSpace::SizeOfObjects() then returns exactly the same value as
PagedSpace::Size(). SizeOfObjects() used to deduct the current LAB,
however this is now more difficult with local heaps. Accessing the
main thread LAB from concurrent threads causes a data race. Also
LocalHeaps have their own LAB, which should be deducted as well to be
uniform with the main thread. However this would be tricky and expensive.
The simpler solution is to do not deduct the main thread LAB anymore.
Bug: v8:10315
Change-Id: I3c47e1a65caca9395737251aa694b295e78c7fb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336090
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69245}
With the new Turbofan variants (NCI and Turboprop), we need a way to
distinguish between them both during and after compilation. We
initially introduced CompilationTarget to track the variant during
compilation, but decided to reuse the code kind as the canonical spot to
store this information instead.
Why? Because it is an established mechanism, already available in most
of the necessary spots (inside the pipeline, on Code objects, in
profiling traces).
This CL removes CompilationTarget and adds a new
NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
various things about a given code kind (e.g.: does this code kind
deopt?).
As a (very large) drive-by, refactor both Code::Kind and
AbstractCode::Kind into a new CodeKind enum class.
Bug: v8:8888
Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69244}
DetachPersistent() sets up PersistentHandles, but didn't properly set
up ordered_blocks_. So PersistentHandles::Contains failed for handles
that were detached from the main thread into PersistentHandles.
Bug: v8:10315
Change-Id: I5374ad64743cd519a9c5e92900c1fa401c4d93ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336801
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69243}
Use the new jobs API for WebAssembly compilation. This avoids having to
schedule as many background tasks as there are worker threads. Instead
the one job specifies the maximum concurrency, which changes dynamically
as new compile jobs become available.
This also avoids the artificial deadline we used to ensure that other
tasks get some share of the CPU resources if needed.
Even though this CL moves actual wasm function completely over to the
Jobs API, other similar tasks (like wrapper compilation) are still using
the Task API and need to be ported in a follow-up CL.
Also, we are still using the same priority for baseline compilation and
tier up. We should split this in a follow-up CL to have two jobs with
different priorities. This will also allow us to only block on baseline
compilation where we currently block on both.
R=ahaas@chromium.orgCC=gab@chromium.org
Bug: chromium:1101340
Change-Id: I5656697753346e5fdb15d578425cdb949ac6e364
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.chromium.try:linux-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280100
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69239}
As this is a unary operation src operands must be the same.
Change-Id: Id6e3b11fdb942596c05c38591379e6d9fd71f19e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332865
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69234}
We can use r0 itself without the need of loading it with "0",
if it is used as the first input of MemOperand.
Change-Id: I71aafea8bba098f925c55eb9127c6b37ac37cb7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332864
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69232}
Swizzles are shuffles that only use values from 1 operand, e.g.
v8x16.shuffle 0 1 2 3 0 0 0 0 4 5 6 7 0 0 0 0 (all the values are < 16).
Match such patterns and emit an optimized codegen that uses less
registers and instructions. Only implemented for x64 for now, the other
backends will come in follow-up patches.
Bug: v8:10696
Change-Id: Iffa694b04c97313eab7d138e4bdad7c0c85cda89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335419
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69231}
Add safepoints to GC methods in Heap. There is still stuff in
Heap::CollectGarbage which might work better or more precise in a global
safepoint. Be conservative here and move everything into the safepoint,
eventually we can start to move code out that is fine to run outside
the safepoint.
Bug: v8:10315
Change-Id: I656dfd72f032eff6f386cec63a02777506650aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335192
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69228}
Only expose top-level functions for DefineOutputs and AllocateRegisters in
the mid-tier register allocator, rather than exposing the MidTierRegisterAllocator
object, to be in-line with AllocateSpillSlots and PopulateReferenceMaps.
BUG=v8:9684
Change-Id: I93dcff77f5e50dab9b373b4415029361078d58e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323361
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69226}
This ensures that large object has exactly the size of a regular page.
Avoids wasting memory due to alignment.
Bug: v8:10315
Change-Id: Ife8051313f1ea8c1fc0ba0afcc4e5db11f27adca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335191
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69225}
LocalAllocationBuffer is used on the background thread so it needs
to use CreateFillerObjectAtBackground for creating filler objects.
Bug: v8:10315
Change-Id: Ifc22d87e1e835cfdd65d82fc79b20ee74b2c87b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336795
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69224}
This was wrong because ObjectBoilerplateDescription is a subclass of
FixedArray. The wrong order didn't cause problems because we explicitly
call the ObjectBoilerplateDescription constructor in the places that
matter.
Bug: v8:7790
Change-Id: I63b6b8741472862d2b1b9b843d7aa2490c620f87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335180
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@{#69219}
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}
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}
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}
PersistentHandles were attached to the LocalHeap when passed in through
the constructor but not when created inside LocalHeap using
EnsurePersistentHandles.
Bug: v8:10315
Change-Id: Id24d36c935776cb0b643521c465763da7fbffd06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326630
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69167}
This is a reland of 13141c8a65
... with a fix for an UB issue of passing null pointers to memcpy()
when size is zero.
TBR=leszeks@chromium.org
Original change's description:
> [zone-compr] Introduce ZoneTypeTraits and ZoneCompression
>
> Also move zone compression flags to src/common/globals.h.
>
> Bug: v8:9923
> Change-Id: Id0a77720e735e2669a1e5eef48e1b4866ad99480
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324255
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69160}
Bug: v8:9923
Change-Id: I2245b81516c39ccea262c282c659ef601af57abf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332165
Commit-Queue: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Reviewed-by: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69166}
If an enum case has a type annotation, the corresponding enum constant
has this type. This is useful for typing context slots.
Bug: v8:7793
Change-Id: I8b91c3bd3686048f98cce3c034eec4e36f925e5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2329631
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69165}
Excluded regions are no longer available to the RegionAllocator, so
should not be freeable so actually enforce that and aAdd a test.
Bug: v8:10454
Change-Id: I51c41cf0bf3d2eeb699b10b1fa02f5465d93b6aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330026
Reviewed-by: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69163}
If we are near the stack limit, calling the proxy method might not work
any more. Instead of crashing because of an empty MaybeLocal, handle
this gracefully.
Drive-by: Minor refactoring in TryGetValue.
R=tebbi@chromium.org
Bug: chromium:1110001
Change-Id: I07e7773768166b3dbea2e6b75a3ab8b24bfeee53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332156
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69161}
This adds new methods AllocateSharedPages, ReserveForSharedMemoryMapping
and CanAllocateSharedPages to v8::PageAllocator, which if overridden
allows the platform to declare that it supports allocation and remapping
of shared memory.
This interface is currently a work in progress so the new methods are
marked "INTERNAL ONLY" and they may change without being first
deprecated.
An implementation of PageAllocator is provided that can allocate and map
shared memory on Linux and Android, but no other platforms are yet
supported. While Windows is not supported the interface has been
designed to make this possible as AllocateSharedPages returns a
SharedMemory object that wraps the shared memory and provides its own
remap function. This should allow the SharedMemory object on windows to
contain a mapping a to hFileMappingObject as required by
MapViewOfFileEx.
Bug: v8:10454
Change-Id: I2e601d49ea14da44867a102c823fa4e341cf0dab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306789
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69154}
The resolvedOptions of Intl.NumberFormat depends on the ICU's
skeleton. sffc change the output of the wildcard from + to *
in ICU67
(ac4540f8a4)
Change the v8 code to use * instead.
Bug: chromium:1108810
Change-Id: I8b0249a5bc4cc199f454c5070635100f68d1f48d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2318272
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69152}
Change all the callers in backend specific instruction-selector
to call the functions in simd-shuffle.h
Also copy over the documentation that was in instruction-selector.h
to simd-shuffle.h.
Bug: v8:10696
Change-Id: Ic9339d6481316f18c19f35c45460e700b45ec38e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327182
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69150}
These are no longer tied to instruction-selector, so move them out into
their own unittests. We can then remove the *ForTesting methods.
Bug: v8:10696
Change-Id: I387cf38290d9602b011ee1d13ee5285ac660f208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326951
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69149}
This is a spec bug in V8. Only call expressions literally of the form
'eval(...)' are considered direct.
Bug: v8:10688
Change-Id: Ia5ac9992db82cad0ad6870119bd94a0b4daee417
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327752
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69148}
This is to group them up and not have classes and methods intertwined.
Change-Id: I8147f06f060932f7b70e478324ce5868d0ffd5d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328786
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69143}
Adds unittests that test the fast register allocator correctly deals
with spills of Phi's between their definition and a predecessor block's
gap move to populate the Phi.
BUG=v8:9684
Change-Id: I17263058d5ac29088895ad3de7b3131315ec8fae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299371
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69141}
Adds support for Phis to be allocated to the fast register
allocator. Registers used for Phis are marked specially between
the point where the Phi is defined, and the gap-move's in the
predecessor blocks which populate the Phi value, since if the
Phi is spilled then all predecessor blocks must also spill the
Phi even if they were already allocated.
BUG=v8:9684
Change-Id: Iebe90495b83df655d3335a7d55874123f3b27f8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299366
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69139}
PersistentHandlesScope works similar to the DeferredHandleScope, but
returns PersistentHandles instead of DeferredHandles on Detach().
Since PersistentHandlesScope takes over filled blocks from the
main thread local handle, remove the block_size_ field and use
kHandleBlockSize instead. This way all blocks have exactly the same size.
Bug: v8:10315
Change-Id: I295cad6f84852f87c55d95572905069443f5698c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324254
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69138}
The DecompressionOptimizationPhase performs MachineRepresentation
changes in the nodes, which causes the node's instruction selection
to avoid decompression.
It is safe to run after we already have a schedule since it does not
drop any nodes.
Bug: v8:9684, v8:7703
Change-Id: I636ae80fa82d0c78878756e9f39e7a14c02803b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324252
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69137}
lvx and stvx require 16-byte aligned addresses.
This CL enables loading and storing to addresses which are not
16-byte aligned.
Change-Id: I5635e857a979520822c8b30bb5477a159e97e6e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327648
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69135}
This reverts commit 76b53b66b0.
Reason for revert: Can't be used easily in embedder (Chromium).
Original change's description:
> [api] Add a SharedArrayBuffersEnabled callback.
>
> - Adds a SharedArrayBuffersEnabled callback and uses it to
> enable/disable SABs per context. The feature flag is used
> if no callback is registered.
>
> Bug: chromium:923807
> Change-Id: I4d3472fcd79b158cb50dc98793aece6dbbb81d93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316901
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69057}
TBR=bbudge@chromium.org,adamk@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:923807
Change-Id: I6e3ddfa9cd64ba3106b4a75ea7a5185f873facc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326952
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69134}
Although the code generator already combines return instructions late
in the pipeline into a common site, there were still superfluous jumps
to that common site left in the code.
Change-Id: I06c885fb0ab6a2c078f9dabdc6616c6881f42c75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284984
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69133}
This prints a message whenever we discard compiled metadata of an SFI.
The message identifies the SFI. I've found this helpful when debugging.
Change-Id: Ib34266199ade2ef88a6bafe32295ab505ce7c899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324260
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69132}
I noticed that, with pointer-compression enabled, in map checks we no
longer load the map as part of the cmp instruction:
movl rcx,[rdx-0x1]
movl rdi,0x8286f8d ;; (compressed) object: <Map(HOLEY_ELEMENTS)>
cmpl rdi,rcx
This CL restores that:
movl rcx,0x82c6f8d ;; (compressed) object: <Map(HOLEY_ELEMENTS)>
cmpl [rdx-0x1],rcx
Change-Id: Ifcc7f34fddf6aa423c0a26066ac124e9757cb9ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320653
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69130}
The bug was that the allocation of the result array (before the loop)
was using the outer frame state, thus returning the allocation's result
(an array full of holes) as the return value of the map operation in
case the allocation triggers a lazy deopt.
Bug: chromium:1104514
Change-Id: I9a6db8a5860472e1b438b6b54414938d61e166c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324249
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69129}
Since we now add the additional required capacity when assessing
StringTable shrinking during LookupKey-caused string insertion, we no
longer have to add a slack capacity. This more closely matches previous
behaviour, which didn't consider the additional required capacity but
did add slack (which, because of rounding to the next power of two,
amounts to the same thing).
Bug: chromium:1108258
Change-Id: I81f513fdc800a2caab76e030c0c5e767cd1360d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324253
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69127}
This is the first step towards implementing a tier-up mechanism from
NCI code to TF. We will follow the existing Ignition-to-Turbofan
mechanics, which are, roughly:
1. Track a bytecode interrupt budget.
2. When exhausted, call the runtime profiler, which increments
profiler ticks for the top frame's function.
3. When a function should tier up, it is marked as such using the
FeedbackVector::optimized_code_weak_or_smi slot / the
OptimizationMarker mechanism.
4. The InterpreterEntryTrampoline checks this slot and calls into
runtime to compile if needed.
5. The finished code is also placed into this slot, as well as
installed on the JSFunction.
6. Again, the IET checks the slot and tail-calls the code object if it
exists.
This CL implements step 1 for NCI code by inserting the new simplified
UpdateInterruptBudget operator at the same spots (and using the same
offsets) as Ignition. When the budget is exhausted, we call a runtime
function that currently does nothing and will be implemented in the
next CL.
Bug: v8:8888
Change-Id: I98c0f8d96f32d515218dc2a76f961d44fe281c86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312778
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69124}
Zap freed local and persistent handles similar to main thread handles.
As a drive-by change, fix the creation of local handles without
LocalHandleScope.
Bug: v8:10315
Change-Id: Ia71bc5419c62ae073928751f57fc221ea11de254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323362
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69121}
Port 1250fd59aahttps://crrev.com/c/2307240
Original Commit Message:
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
Change-Id: I2c515e095730ba3880b639bdd85504e644b64e53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2325258
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#69117}
This cl also
1. Fixes a bug in effect-control-linearizer where we should have
converted fixed array length from Smi to integer
2. Also prints deopt location for the new "bailout" deopt type on
--trace-deopt.
Bug: v8:10582, v8:9684
Change-Id: Iafc5e8abbca5252a8783a5a1184a1667a7f708a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297460
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69115}
LocalHeap should only be used on the heap it was created on.
Bug: v8:10315
Change-Id: Ia06f0169d39b4148b356568795f4e316361a1e9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323358
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69114}
1. Adds a flag to specify if minimorphic accesses should be optimized
using dynamic map checks operators. This flag is disabled by default.
2. Builds the PropertyAccessInfo from handlers instead of reading it
from maps for minimorphic accesses
3. Uses DynamicMapChecks operator to lower the minimorphic accesses.
Bug: v8:10582, v8:9684
Change-Id: I0b7b26b876f9ad12d6fc38788137b66ee6455aeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241524
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69112}
Currently WebAssembly always goes through the ArgumentsAdaptorTrampoline
builtin for wasm-to-js calls as soon as there's a mismatch between the
actual number of arguments and the expected number of arguments.
This can be made faster in cases where:
1. the callee has "don't adapt arguments" set, which is often the case
for builtins, or
2. the callee has "skip adapt arguments" set, which is often the case
for strict mode functions.
TurboFan already supports this for JS calls:
https://chromium-review.googlesource.com/c/1482735;
explainer document:
http://bit.ly/v8-faster-calls-with-arguments-mismatch.
Even though it is probably not as common to have arity mismatches in
Wasm->JS calls as it is in JS->JS calls, this still seems a worthwhile
optimization to do.
This CL ports the TurboFan fix to WebAssembly. In particular, the CL
introduces a new WasmImportCallKind (kJSFunctionArityMismatchSkipAdaptor)
for the case where the call to Builtins_ArgumentsAdaptorTrampoline
can be skipped, and modifies WasmImportWrapperCache::CacheKey to also
consider the arity of the imported JS function.
A micro-benchmark for this change can be found here:
- https://gist.github.com/paolosevMSFT/72c67591170d6163f67c9b03a7e12525#file-adapter-cc
- https://gist.github.com/paolosevMSFT/72c67591170d6163f67c9b03a7e12525#file-adapter_test-js
With this benchmark, we can save a 40% overhead of
Builtins_ArgumentsAdaptorTrampoline for calls that pass too many
arguments, while the savings for calls that pass too few arguments are
less impressive:
Before After
callProperApplication: 563 ms 566 ms
callOverApplication1: 972 ms 562 ms
callOverApplication2: 962 ms 562 ms
callUnderApplication: 949 ms 890 ms
Bug: v8:8909
Change-Id: Id51764e7c422d00ecc4a48704323e11bdca9377f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317061
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69110}
This gives the GC a location where it can interrupt background
compilation.
Bug: v8:7790
Change-Id: I8cf40e9c9b69c00fdfd5d59ed87e83137e481fb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2310366
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69109}
Adds support for populating reference maps to the fast
register allocator. In order to calculate whether a stack slot
is live at a given instruction, we use the dominator tree to
build a bitmap of blocks which are dominated by each block.
A variable's spill operand is classed as alive for any blocks that are
dominated by the block it was defined in, until the instruction index
of the spill operand's last use. As such, it may be classified as live
down a branch where the spill operand is never used, however it is safe
since the spill slot won't be re-allocated until after it's last-use
instruction index in any case.
BUG=v8:9684
Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69108}
Adds support for tracking the instruction range of spilled operands,
and then allocating spill slots to these ranges. It also adds some
unittests covering spill slot allocation.
Spill slots are allocated in a linear fashion, running through the
instruction stream in a linear order, ensuring that no spill operand
is allocated to a same spill slot that is already assigned to during
this whole start / end range. This isn’t optimal, since it doesn’t
take into account holes in these ranges (e.g, blocks between start
and end that aren’t dominated by the start), but in practice rarely
leads to more than one extra spill slot being allocated compared to
the current allocator.
BUG=v8:9684
Change-Id: Iedee7bcf552080e5b4b6a2f4e96b78b6c1396cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297470
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69107}
Also use outer-function name as a ZONE_NAME instead of file:line
and give explicit names to parser and preparser zones.
Bug: v8:10572
Change-Id: I9b5acb23322889d8538a34bc888fd6f610eb6893
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2322627
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69104}
Port 1250fd59aa
Original Commit Message:
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
R=evih@google.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ib1f14081779adaf3668c4936ba6afde0a782ce0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323310
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69103}
On 32-bit systems the calculation could overflow, leading to an illegal
limit of the LAB. Cast to uint64_t to avoid this. Add DCHECKs to
catch this earlier.
Bug: chromium:1110214, v8:10315
Change-Id: I73679a2daeb3b83bb303d411c77782a2172e98cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320654
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69101}
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
Bug: v8:10701
Change-Id: Id8cd1771f26922927363b715d8a6ffd384a143ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307240
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69097}
As a downside, class-level static variables of FutexEmulation
now have to be local to the .cc file.
Bug: v8:10239
Change-Id: I3d00c65289f346cf2b16fea657f47bff69863b0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319989
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69096}
If we're close to a stack overflow when starting a script compile, we
may get into a state where main-thread compilation would stack overflow,
but background-thread compilation wouldn't. This triggers a failure of a
CHECK under --stress-background-compile, but isn't actually an
interesting failure.
So, we loosen this CHECK to allow the main-thread having a stack
overflow (strictly speaking, a RangeError) to count as a "success" for
the purposes of comparing against a background compilation success.
Bug: v8:10757
Change-Id: I7d687b52d178973b421c42ca0d89b4da0357232a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320649
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69092}
As an experiment to see how performance is impacted when changing
inline definitions to normal definitions in a .cc file, this CL moves
js-function-inl.h to js-function.cc.
Bug: v8:10749
Change-Id: I97c3a0b7d20217f444c6891442bbe3c34f3b0cc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315993
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69091}
Isolate::PromiseHasUserDefinedRejectionHandler no longer descends
recursively the outer_promise chain but uses an std::stack to avoid
stack overflows with very long promise chains.
Change-Id: Icdf86a34d89b734adc7139357b2ba6b37a7882ad
Bug: chromium:1096139
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316298
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69090}
If multiple isolates were involved, we did not always hit the breakpoint
reliably in all isolates.
This CL fixes this flake this via two changes:
1. Remove breakpoint info when tiering up.
If we keep the breakpoint information, a second isolate that later
sets the same breakpoint will see that the breakpoint already exists,
and will not set it again, even though the code containing the
breakpoint has been replaced at that point.
This fixes a flake in the debug/wasm/breakpoints test.
2. Don't overwrite code with breakpoints by default "tiered down" code.
This is achieved by introducing another state in the {ForDebugging}
enum which marks that code contains breakpoints. Otherwise it could
happen that two isolates start tiering down (both recompiling missing
functions in Liftoff), one isolate finishes and immediately sets a
breakpoint, then the other isolates finishes and overwrites the code
with breakpoints by the usual {kForDebugging} code.
Setting breakpoints is synchronized already, so overwriting
breakpoint code with other breakpoint code is always safe.
R=thibaudm@chromium.org
Bug: v8:10611, v8:10359
Change-Id: I171d86b110a54f9eb5e4c3fa35108638904212e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316080
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69088}
Currently, when running with --trace-turbo, V8 generates a different
.json file for each wasm-to-js thunk that it compiles, but these files
all have the same name "turbo-wasm-to-js-0.json", and only one file is
generated.
This makes it difficult to actually examine the difference in the IR
for this call wrappers produced for different signatures.
This patch fixes this by naming each trace file as:
"wasm-to-js-<kind>-<signature>-0.json", like for example
"turbo-wasm-to-js-5-ii-i-0.json".
Change-Id: Iebb73829cddd4f6bbf9d02ed1ce94a80dcfa5ca7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316834
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69085}
https://tc39.es/proposal-intl-segmenter/
TC39 passed Intl.Segmenter to stage 3 in Jul 21.
This CL move our earlier prototype to the current spec.
Bug: v8:6891
Change-Id: I07234beed54f671c26bdbfb3983c5bc2fa5a29b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219413
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69080}
Currently, only a scriptURL is reported, which can be over-written by
sourceURL comments of the script. This means a script can basically
claim to come from anywhere. This means that DevTools doesn't know the
resource name the embedder provided if there is a sourceURL comment.
This CL adds a `embedderName` field to the scriptParsed and
scriptFailedToParse events that reports the name the embedder
associated with the script.
Bug: chromium:974543
Change-Id: I9863f878f57638174847890d9a3818952b1efc27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317310
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69078}
When we add safepointing, the source position address might change.
Then, we need to use the handlified version for both concurrent-inlining
and not.
The logic for retrieving the Handle can be encapsulated in the
BytecodeArrayRef, which can be reused in the other source_position_*
methods.
Bug: v8:7790
Change-Id: I3e5f937eb06153449cf6f720a2a4321cb338d903
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316301
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69076}
This flag's name is slightly incorrect as it is possible to have more
maps than this in the feecback vector.
This flag doesn't account for deprecated maps in the feedback
vector. To make this explicit, we change the flag to indicate that
this only counts valid maps.
Bug: v8:10582
Change-Id: Ib0cc425a03d590bb21184fc6b104d0ebee1d5b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319992
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69075}
When mksnapshot fails on a static assert in Torque, print the
statement and position from the Torque source. To enable special
treatment, change the syntax of static asserts in Torque
from StaticAssert() to static_assert() to align with assert() and
check() statements.
Bug: v8:7793
Change-Id: Idda8e3c342bdcefc893ff297f8d7727d2734c221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317314
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69069}
This CL allows LocalHandles to be dereferenced by the same thread that
created them, even if we have a DisallowHandleDereference scope.
Bug: v8:7790
Change-Id: Ie227aaa4152c887d0d9c913dfa35217166726614
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316111
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69068}
Introduce explicit fast path for allocation from LAB. The slow path
refills the LAB and allocates again. Other changes:
1) Move slow path methods out of the header file
2) AllocateRaw(Aligned|Unaligned) are now private methods. All
allocations need to go through AllocateRaw for NewSpace now.
Bug: v8:10315
Change-Id: Iee2bd7b74aa49be8b20d89fefeb2e087575d532c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319987
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69061}
Add methods NotifyBytes(), NotifyObject() and NextBytes() to
AllocationCounter. Methods are unused for now.
Move AllocationObserver::Step after AllocationCounter methods as well.
Use SetTopAndLimit as bottleneck instead of allocation_info_.Reset.
Bug: v8:10315
Change-Id: I30049cb02e873bb08ebce606a491d99130421227
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316103
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69060}
- Adds a SharedArrayBuffersEnabled callback and uses it to
enable/disable SABs per context. The feature flag is used
if no callback is registered.
Bug: chromium:923807
Change-Id: I4d3472fcd79b158cb50dc98793aece6dbbb81d93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316901
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69057}
Using uint8_t[] causes decay to pointer issue, which manifests in
copying garbage values in the call to WriteLittleEndianValue. Change it
to use a std::array, which doesn't have the decaying behavior.
Also add a regression test from comment#6 of the linked bug.
Bug: v8:10731
Change-Id: I4a1ca69fe99806642e9931625ca7aeab6663f955
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316465
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69052}
These functions match on specific patterns of shuffle that have more
optimized implementations. Moving them out of instruction-selector
allows us to reuse them in Liftoff. Most of these pattern matching
functions do not depend on InstructionSelector, since they work on byte
arrays. (The only one is CanonicalizeShuffle, which swaps node inputs.)
This is only the first pass of moving those functions out. In particular
we can clean things up more by moving the tests out of
instruction-selector as well. Those will come in follow-up changes.
Bug: v8:10696
Change-Id: I4a4333cd8c0259875a672179e72d34dad5f7a008
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308057
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69051}
