TPH doesn't support multiple mutators at the moment, so concurrent_inlining is disabled.
Thus we don't need to support `PublishPendingAllocations` for now.
Bug: v8:11641
Change-Id: I26f63f4093027878563c15de594a0a6bbef31c0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2849819
Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74213}
Place DCHECKs in per-space allocation functions and concurrent allocation functions
to assert TPH is not enabled.
For per-space allocation function, they should be redirected to TPH.
For concurrent allocations, TPH doesn't support it at the moment.
Bug: v8:11641
Change-Id: Ib7292bc03132353b0555d9cbd5b49936f4a6de76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2849817
Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74211}
1. add saving for s9, s10, s11
2. remove saving for gp.
3. fix maintain of fp (which alias to s0).
Reference of calling convention source:
https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf.
Change-Id: I7898f52e55df3976dccd736b72249f4fe28dd359
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848476
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#74208}
Bug: v8:11692
Change-Id: I89cdb3d7102123f63fc66106c35962d0578222c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2851878
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74205}
This is a reland as-is of
https://chromium-review.googlesource.com/c/v8/v8/+/2831488, which got
lost in the js-heap-broker.cc to heap-refs.cc transition.
Bug: v8:7790
Change-Id: I9dd9e77a665e70feb90457a906a221926a3c0b94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848411
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74202}
When add/sub with immm in [-4096, -2049] || [2048, 4094],
it can be split two addi/subi instr.
Change-Id: I94b93763c33fa5ef31c5ec4d23cbc5580a93ed1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848732
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Brice Dobry <brice.dobry@futurewei.com>
Cr-Commit-Position: refs/heads/master@{#74199}
xori rd, rs, 0x1 mean is that negating bit 0 of rs.
So we can delte xori and invert the condition of the branch.
Change-Id: I318b7a2def6ec5d848757f85623564922abfcdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2847673
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Brice Dobry <brice.dobry@futurewei.com>
Cr-Commit-Position: refs/heads/master@{#74197}
This reverts commit d2ce574457.
Reason for revert: We reverted the early canonicalization change, so we need to worry about non-canonicalized shuffles now.
Original change's description:
> [wasm-simd][arm64] Update f32x4.mul(dup) pattern matching
>
> We now canonicalize earlier in the pipeline, and don't need to worry
> about non-canonicalized shuffles.
>
> Bug: v8:11542,v8:11257
> Change-Id: If9f5c44061465be339c98e479fd8c5a437bbd74b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778673
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73645}
Bug: v8:11542
Bug: v8:11257
Change-Id: Ib492b3ab7ad140193975d2641999c12c9697e27b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850630
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74193}
- Move LsanPageAllocator to base;
- Use LsanPageAllocator in PageBackend that serves managed C++
objects;
- Remove spurious TODO for GCInfoTable which should not use the
LSAN-aware backend;
Bug: chromium:1056170
Change-Id: I2caa11443ab44da5164f1c29339e302bffb49228
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850157
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74192}
All existing usages are changed to Factory::NewFixedArray(). The
motivation for the removal is that the function is unsafe and easy
to misuse.
Note that NewUninitializedFixedArray has been already changed to
initialize the result as an experiment with 3%-13% regression on
a few SixSpeed microbenchmarks and no impact on larger benchmarks.
Change-Id: I2e084bc03b2636aa6d368ca255970566a7ce222e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846895
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74186}
During background compilation, we check
SharedFunctionInfo::HasBreakInfo() to see if the function has
breakpoints for debugging, generally deciding not to inline the
function if so. We were concerned about the status of this bit
changing on the main thread. Happily, the main thread deoptimizes
all functions that inline the given function, and shuts down all
background compilation jobs as well. So it is not a meaningful
concern (that of say, ignored breakpoints). Updated a comment to
record this finding.
Bug: v8:7790
Change-Id: I7adbc5d19fc45eb7f4df1400c33f5988d9dac58d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848409
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74183}
This will help reducing the time needed to reach a Safepoint() on the
main thread. During startup main_thread_local_isolate() is not
initialized when Heap::AllocateRaw() is invoked. Solve this by
only running Safepoint() after deserialization is completed.
Bug: v8:10315
Change-Id: I281fdbe5cebcd7946d687f56676c0d563792fde5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835714
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74181}
Instead of running a second pass of the scheduled graph after
effect control linearization to do machine lowering, integrate
the machine lowering reducers (MemoryLowering and SelectLowering)
into the graph assembler used by the effect control linearization.
This saves running through the graph and re-maintaining the schedule
for the second time, reducing overhead in Turboprop.
BUG=v8:9684
Change-Id: Ib0fed19089287c8e801a063333cb8404181411db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848474
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74178}
We were inconsistent in handling offsets >= 2GB on 32-bit systems. The
code was still relying on this being detected as statically out of
bounds, but with the increase of {kV8MaxWasmMemoryPages} to support 4GB
memories, this is not the case any more.
This CL fixes this by again detecting such situations as statically OOB.
We do not expect to be able to allocate memories of size >2GB on such
systems. If this assumptions turns out to be wrong, we will erroneously
trap. If that happens, we will have to explicitly disallow memories of
such size on 32-bit systems.
R=jkummerow@chromium.org
Bug: v8:7881, chromium:1201340
Change-Id: Ic89a67d38fb860eb8a48a4ff51bc02c53f8a2c2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848467
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74175}
The property kInObjectPropertiesStartOrConstructorFunctionIndexOffset
was set as relaxed due to races with the layout_descriptor
(https://chromium-review.googlesource.com/c/v8/v8/+/555210/). The
layout_descriptor was removed with the removal of double field unboxing.
We are able to turn those property's accessors into non-atomic ones
since they are set at construction time.
Bug: v8:7790
Change-Id: I25c53f0e00718cca72ba86f8475af9ecefb7ba3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843359
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74174}
It's unfortunate that there is both a LocalIsolate template parameter,
and an actual LocalIsolate class. Clean this up by renaming the
template parameters to IsolateT
Change-Id: Iecefc3eca5aeb7bbd21e78818b90f9e75cdff10f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846880
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74173}
Prior to this CL, Refs were defined through four lists:
HEAP_BROKER_SERIALIZED_OBJECT_LIST
HEAP_BROKER_POSSIBLY_BACKGROUND_SERIALIZED_OBJECT_LIST
HEAP_BROKER_BACKGROUND_SERIALIZED_OBJECT_LIST
HEAP_BROKER_NEVER_SERIALIZED_OBJECT_LIST
Due to the way FooData objects are constructed (a long if-else chain
generated from these lists), the order of entries within the lists and
also between lists was important. In particular, subtypes had to
appear before all their supertypes. Within one list this was doable,
but with the split into 4 different lists this invariant cannot hold
in practice.
This CL refactors the four lists back into a single list to make
observing the invariant possible with upcoming changes. The new
unified list contains the RefSerializationKind as a second argument.
Related changes are not very interesting, except for
TryGetOrCreateData which now uses a set of templated functor objects
for setup (this was necessary to handle different FooData constructor
signatures).
Bug: v8:7790
Change-Id: Ia4c030c767830be4253cf41e3aaf67454f1cbef6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843351
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74171}
Prior to this patch, `new RegExp('a/b')` logs the following in
the DevTools Console:
/a/b/
This is syntactically invalid.
This patch fixes this while simplifying regular expression printing
in general by leveraging `RegExp#toString`, instead of duplicating
the logic on the inspector side. This is possible thanks to the recent
work on making `RegExp#toString` more robust (v8:1982).
Bug: chromium:1202013, v8:1982
Change-Id: I14ccc1892f4a99361ad170fea608ace630740991
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848463
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74169}
On a per-job basis, --turbo-direct-heap-access should be equal to
whether concurrent inlining is enabled. We simplify involved logic by
removing the flag, and replacing all access to
- FLAG_turbo_direct_heap_access, and
- FLAG_concurrent_inlining
inside compiler/ with
OptimizedCompilationInfo::is_concurrent_inlining() (or derived values).
Bug: v8:7790
Change-Id: I64818e0e1004dded08c784ef1c4bdfd2af990a59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843345
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74166}
.. which used to be implemented by calling BooleanValue eagerly on all
seen heap objects during serialization. 1) it's wasteful to call this
on every object, 2) this was blocking conversion of HeapObjectRefs to
not require main-thread serialization.
This CL replaces the old pattern by a thread-safe TryGetBooleanValue
method, which may fail in some cases (e.g. when trying to read into a
HeapNumber).
Bug: v8:7790
Change-Id: I9d4ab7725231adce0b488c4c08c1f4bac78ce3c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839557
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74165}
.. by locking the MapUpdater lock during MapData construction.
Note this only applies to basic MapRef/MapData construction. Some
methods, in particular MapRef::SerializeFoo methods, are not yet
background-serializable in general and require more work.
Bug: v8:7790
Change-Id: I473e78c82012ab6abc5a0633a4d34c4a40a3fb77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839553
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74164}
This is the second CL in a line of two (see crrev.com/c/2835237) to
bring write-protection to the WebAssembly code space. The previous CL
changed the page permissions from W^X (only either writable or
executable can be active, but never both) to write-protection (due to
concurrent execution in the main thread). However, write-protection
still did not work, because in several places the code space is
modified without properly switching it to writable beforehand.
This CL fixes --wasm-write-protect-code-memory such that it can now be
enabled again (with potentially high overhead due to frequent page
protection switches). For that, it adds the missing switching to
writable by adding {NativeModuleModificationScope} objects (similar to
the already existing {CodeSpaceWriteScope} objects for Apple M1
hardware).
This CL also fixes a race condition between checking for the current
writable permission and actually setting the permission, by protecting
the counter of currently active writers with the same lock as the
{WasmCodeAllocator} itself. (Before multi-threaded compilation, this
was not necessary.)
Finally, this CL also changes the {Mutex} protecting the
{WasmCodeAllocator} to a {RecursiveMutex} because it can be requested
multiple times in the call hierarchy of the same thread, which would
cause a deadlock otherwise. Since {TryLock()} of a {RecursiveMutex}
never fails, this also removes the (now failing) DCHECKs.
R=clemensb@chromium.org
CC=jkummerow@chromium.org
Bug: v8:11663
Change-Id: I4db27ad0a9348021b0b663dbe88b3432a4d8d6b5
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835238
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74163}
Since WasmToJSWrappers are on-heap Code objects, they should use
the "kCallBuiltinPointer" mechanism to call builtins.
AFAICT this only affected the call_ref instruction.
Bug: v8:9495
Change-Id: I2d55e8f2504787a8a92410868ced8d5ce63a5376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846896
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74157}
Currently the function normalizes only old sparse backing stores.
This patch removed the age check to decouple the heuristic from GC.
Change-Id: I9b7f787315b2b8facfa35358143173f7d207c8da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846897
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74156}
This is a reland of df4dae7765
Revert reason looks like an unrelated existing flake (https://crbug.com/v8/11634)
Original change's description:
> [arm] Make the constant pool check deadline smarter
>
> Rather than having periodic constant pool checks that almost always fail
> (because the constant pool deadline isn't close enough, or even because
> there's no constant pool to emit at all), set a single deadline on the
> first constant pool insertion which expires just before the maximum
> distance to the constant pool. Constant pool checks around unconditional
> jumps happen irrespective of this deadline.
>
> In particular, this is made possible by fixing the incorrect assumption
> that the constant pool can be emitted out of order. The new assumption
> (that the emission is in-order) is validated with a CHECK.
>
> Bug: v8:11420
> Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74141}
Bug: v8:11420
Change-Id: I1cc5ca9082da26ab225dee8d8ea22c385c6cc1d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848468
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74154}
We could end up in a baseline entry trampoline without having
baseline code, because of an unhandled interaction in the debugger
(discarding baseline code) and the deoptimizer.
Bug: chromium:1199681
Change-Id: Ia33bb4d64903dd989728465b3d83a88b84597a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843820
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74153}
The ToString intrinsic isn't used anymore, since there is now a ToString
bytecode, so we can remove it.
Change-Id: I5ed121ae4d117660e1ee8a64a2b30e1fb054a886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848465
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74151}
Prior to this patch, the RemoteObject for e.g. `/x/d` got a
`description` that omitted the new `d` (`hasIndices`) flag.
Bug: v8:11684, v8:9548
Change-Id: I774fbd9620c6f3f2f19b819c9009fab7cc2e3229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848460
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74148}
This CL applies the following changes:
- JSCallReducer no longer generates a CheckBigInt in front of the
generated BigIntAsUintN.
- This results in a slight change of the semantics of the latter, which
now includes the necessary type check. Typer and Verifier are changed
accordingly.
- The BigIntAsUintN operator is now effectful, since it can now deopt.
- IrOpcode::kBigIntAsUintN is now lowered in SimplifedLowering instead
of EffectControlLinearizer, the necessary type check is introduced
by the RepresentationChanger.
- Adds a small mjsunit test to check the correct deoptimization behavior
of optimized BigInt.asUintN.
==> Remove UseInfo::TruncatingWord64()!
Drive-by: Fix an issue in ChangeUnaryToPureBinaryOp when the new_input
is at index 1.
Drive-by: Introduce an %Is64Bit() intrinsic to allow tests to
distinguish 32 and 64 bit architectures.
Bug: v8:11682
Change-Id: I448f892d3bd2280d731ae5b248c833de8faf1bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843816
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74147}
This reverts commit df4dae7765.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20-%20debug/18512/overview
Original change's description:
> [arm] Make the constant pool check deadline smarter
>
> Rather than having periodic constant pool checks that almost always fail
> (because the constant pool deadline isn't close enough, or even because
> there's no constant pool to emit at all), set a single deadline on the
> first constant pool insertion which expires just before the maximum
> distance to the constant pool. Constant pool checks around unconditional
> jumps happen irrespective of this deadline.
>
> In particular, this is made possible by fixing the incorrect assumption
> that the constant pool can be emitted out of order. The new assumption
> (that the emission is in-order) is validated with a CHECK.
>
> Bug: v8:11420
> Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74141}
Bug: v8:11420
Change-Id: Ib822425749df33fb22a38d317c107a523b382e01
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846899
Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74144}
JS-to-Wasm wrappers embed heap constants (like the undefined value), and
those heap values are being accessed during compilation for tracing.
This is not a data race, since those values are read-only. But if the
isolate dies while we are compiling those wrappers, we might read from
the heap after it has been free'd.
Ideally we would not access the isolate or the heap at all during
compilation, but delaying all tracing until the "finalization" phase is
not feasible, and removing the heap value printing from tracing would
significantly regress quality of this tracing.
Hence this CL only fixes the actual issue: That we keep compiling
wrappers when the isolate is already gone. It does so by introducing an
{OperationsBarrier} per isolate that is being taken by each thread that
executes wrapper compilation, and is used for waiting for background
threads to finish before the isolate shuts down.
Additionally, we actually cancel all compilation if a module dies (or
the isolate shuts down) before it finished baseline compilation. In this
state, the module cannot be shared between isolates yet, so it's safe to
fully cancel all compilation. This cancellation is not strictly
necessary, but it will reduce the time we are blocked while waiting for
wrapper compilation to finish (because no new compilation will start).
R=thibaudm@chromium.orgCC=manoskouk@chromium.org
Bug: v8:11626, chromium:1200231
Change-Id: I5b19141d22bd0cb00ba84ffa53fb07cf001e13cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846881
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74142}
Rather than having periodic constant pool checks that almost always fail
(because the constant pool deadline isn't close enough, or even because
there's no constant pool to emit at all), set a single deadline on the
first constant pool insertion which expires just before the maximum
distance to the constant pool. Constant pool checks around unconditional
jumps happen irrespective of this deadline.
In particular, this is made possible by fixing the incorrect assumption
that the constant pool can be emitted out of order. The new assumption
(that the emission is in-order) is validated with a CHECK.
Bug: v8:11420
Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74141}
BUG=v8:9684
Change-Id: Ia63928e67dd714690b4f54c14361c6ee5e81f604
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843809
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74139}
Untangles the non-tracing GC optimization (Scavenger) that allows for
dropping objects that are only reachable from certain API references
from EmbedderHeapTracer. Instead, allow setting it on Isolate.
This allows for using the optimization when using cppgc.
Chromium-side: https://crrev.com/c/2844587
Bug: chromium:1056170
Change-Id: I20f28dd84c808872c7f9559c8c168e828794dd1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844657
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74135}
Changes:
- Reintroduce CALL_INTERFACE() and use it over
CALL_INTERFACE_IF_REACHABLE_AND_OK() in contexts where
current_code_reachable_and_ok_ is known to hold.
- Add V8_LIKELY annotations.
Bug: chromium:1201718
Change-Id: I6a448a8955ecec20fdddef636d563cb1b5a93679
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846886
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74134}
Using the added lxvx and stxvx instructions, we can load and
store vector register values in a single instruction.
MRR encoding does not have a 16 byte alignment requirement.
Change-Id: I9c1d80fd867a0e79d3390e4a05e08cdf2a2e4835
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2845734
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74130}
Doing a `!(B > A)` which is equal to `A >= B`. This way
we use one less instruction.
Change-Id: I49d50f11096e2d542eaabab82c17225c83e89b63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846980
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74125}
Unordered floating-point (non-)equality is implemented using two flags
on x64: kUnorderedNotEqual as "not_equal OR parity_even" and
kUnorderedEqual as "equal AND parity_odd". Only the first flag was
checked.
This change fixes the kUnorderedNotEqual case by emitting a second
cmov to also move the "true" value if the parity_even flag is set. The
kUnorderedEqual case is covered by inverting the condition in the
instruction selector.
This should also be optimal according to the code emitted by clang -O3
for equivalent C++ code.
Drive-by: remove unused overload of EmitWithContinuation.
R=neis@chromium.orgCC=ahaas@chromium.org
Bug: chromium:1200184
Change-Id: Iae438d29fb5897ca910a154f140a5a6a904490ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844651
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74122}
Currently the --single-generation flags disables inline allocations
and forces all allocations to go via runtime where they are redirected
to the old generation.
This patch implements the young to old redirection in CSA and TF.
Bug: v8:11644
Change-Id: Ie945ba684fb0f41d5414a05be2f25245d4869d6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839010
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74121}
Until this CL, the JSHeapBroker::GetPropertyAccessInfo (GPAI) process
was as follows:
1. GPAI is called on the main thread (MT) during the serialization
phase to create and cache PAIs.
2. GPAI is called again from the background thread (BT); only cached
PAIs from step 1 are usable.
As part of concurrent inlining, the goal is to move GPAI fully to the
background thread. This CL takes a major step in that direction by
making GPAI itself callable from the BT without resorting solely to PAIs
that were previously cached on the MT.
There are two main reasons why GPAI previously had to run on the MT:
a) Concurrent access to Maps and other heap objects.
b) Serialization and creation of ObjectRefs for objects discovered
during GPAI.
This CL addresses only reason a) and leaves b) for future work. This
is done by keeping the two-pass approach, s.t. the initial call of
GPAI on the MT discovers and serializes objects. We then clear all
cached PAIs. The second call of GPAI on the BT thus runs full logic in a
concurrent setting.
Once all relevant objects (= maps and prototypes) no longer require
MT-serialization, reason b) is also addressed and the first pass can be
removed.
The new logic is implemented behind the runtime flag
--turbo-concurrent-get-property-access-info (default true), intended
to be removed in the future.
Bug: v8:7790
Change-Id: Idbdbfe091d7316529246a686bb6d71c2a0f06f8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2817793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74120}
Bug: v8:11675
Change-Id: I8046e61d92b502a8c96f11e3ecfc528544c6ba97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843953
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74114}
As we can still intend to run the web-exposed profiler outside of an
origin-isolated environment, add support back for filtering by
v8::Context.
This reverts commit 05af368100.
Bug: chromium:956688
Change-Id: Idd98bea3213b5963f689a04de6c3743073efc587
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2785806
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#74112}
Instead of {func-index}+{pc of instruction relative to function}, make
it {func-index}:{pc of instruction in module}. This is more consistent
with existing conventions
(https://webassembly.github.io/spec/web-api/index.html#conventions) and
other tools (like output of wasm-objdump).
Bug: v8:10773
Change-Id: I7ceecafd984e2d1adbb57266e1f7448762e23ac9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2842267
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74110}
After appending 'unimplemented instruction' we need to increase the data
pointer to avoid an endless loop and to fulfill a later DCHECK.
R=jkummerow@chromium.org
Bug: chromium:1201114
Change-Id: I707809f81a4d9a6b3653b94b4836482c006b76ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843819
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74108}
This reverts commit fd16e67e49.
Reason for revert: TSAN no-CM flaky failures https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/3413
Original change's description:
> Reland "[compiler] Perform MapRef's SupportsFastArray methods concurrently"
>
> This is a reland of ebd9dcdaac
>
> Reason for reland: std::atomic<> only works for primitive types i.e. it
> does not work for Object. We can change it to read/write the Object's
> Address, instead.
>
> Original (reverted) CL can be seen in PS1.
>
> Original change's description:
> > [compiler] Perform MapRef's SupportsFastArray methods concurrently
> >
> > We are safe to go through the native_contexts_list_ since we do it
> > through IsAnyInitialArrayPrototype which disallows the GC. Furthermore,
> > we read that list with an acquire load which guarantees that the fields
> > have been initialized.
> >
> > Bug: v8:7790
> > Change-Id: I778d51f4ead44e472f842693a7e9ff577d6acfe3
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826541
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#74086}
>
> Bug: v8:7790
> Change-Id: I721c3a1e962951b0bc073dc74baf7fbeababc243
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843813
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74104}
Bug: v8:7790
Change-Id: I4efa8165b680eaa6c5c525d85d21962e6a5b1abb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843822
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74106}
This is a reland of 47077d9449 without
changes. The revert was false alarm.
Original change's description:
> [compiler] Fix more truncation bugs in SimplifiedLowering
>
> Bug: chromium:1200490
> Change-Id: I3555b6d99bdb4b4e7c302a43a82c17e8bff84ebe
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2840452
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74097}
Bug: chromium:1200490
Change-Id: I75cac59050bc393d157a1ee5bed776c8986a7bbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843817
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74105}
This is a reland of ebd9dcdaac
Reason for reland: std::atomic<> only works for primitive types i.e. it
does not work for Object. We can change it to read/write the Object's
Address, instead.
Original (reverted) CL can be seen in PS1.
Original change's description:
> [compiler] Perform MapRef's SupportsFastArray methods concurrently
>
> We are safe to go through the native_contexts_list_ since we do it
> through IsAnyInitialArrayPrototype which disallows the GC. Furthermore,
> we read that list with an acquire load which guarantees that the fields
> have been initialized.
>
> Bug: v8:7790
> Change-Id: I778d51f4ead44e472f842693a7e9ff577d6acfe3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826541
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74086}
Bug: v8:7790
Change-Id: I721c3a1e962951b0bc073dc74baf7fbeababc243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843813
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74104}
For handles and external refs, use Move32BitImmediate directly rather
than mov -- mov will first try more compact encodings which will almost
certainly fail for embedded pointers, so it's not worth trying to use it
in baseline compilation where the compiler speed matters.
Bug: v8:11420
Change-Id: Ic0ed9f95d28302ae9737567aa863dc93666239e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843814
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74103}
This CL hardens the test function for unwrapping the C++ object to
only do so if the correct API object is passed from JS.
Bug: chromium:1201057
Change-Id: I81eb16efe2711bd788c775e3bcb712720bbe4782
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843347
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74102}
Changes:
- Remove TypeCheckBranchResult. Change TypeCheckBranch() to return bool.
Refactor call sites to reflect this (decouple current code
reachability check from type check).
- Unify TypeCheckBranch(), TypeCheckFallthrough(), and the type-checking
part of Return() into TypeCheckStackAgainstMerge().
- Make sure all TypeCheck* functions are only called within VALIDATE.
- In graph-builder-interface, rename end_env -> merge_env to reflect
its function for loops.
- Change expected error messages in some tests.
Change-Id: I857edc18db9c2454ad12d539ffe7a10e96367710
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839560
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74100}
This CL extracts CommandLineAPIScope from V8Console and exposes it
as V8CommandLineAPIScope. Also, it exposes V8InspectorSession::createCommandLineAPI.
These changes will be used by InspectorPageAgent to install command
line APIs when evaluating scripts added using CDP's command
Page.addScriptToEvaluateOnNewDocument.
Chromium CL: https://crrev.com/c/2835786
Doc: https://docs.google.com/document/d/1zGG7-NZMb-aOfFfHf1u4VsP4C-lZettopCvYDC6pkBw/
Bug: chromium:1200705
Change-Id: I39b27f957cfb6d682ea84e385eaf25d09d261b58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835712
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74096}
Similar to the recent change to --code-comments, make --debug-code a
build-time enabled flag, enabled by default on debug builds.
This also removes the emit_debug_code() option from the assembler,
instead using the flag directly (there were no cases where this option
didn't match the global flag).
Change-Id: Ic26b0d37b615a055508c9dda099ffbe979eae030
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843348
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74095}
Based on some test compiles (of three.js and jquery) we can get a decent
estimate of expected bytecode offset table size for a given bytecode
size. Reserve this expected size to avoid resize overhead.
Bug: v8:11420
Change-Id: I8288b01fa796e765a20b11219687fa3d23272416
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843354
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74093}
Since there usually aren't many pending 32-bit constants, we can avoid
the cost of malloc/free for most compiles by using a base::SmallVector
instead of std::vector.
I picked a value of 32 entries as the SmallVector's inline size, based
on compiling three.js and jquery with Sparkplug, and printing the size
of the constant pool when emitted. 93% of emitted constant pools had
<=32 entries.
Bug: v8:11420
Change-Id: I7d62da74c60feae08f8a4b16b1e7f93ea69d2c95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2840447
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74092}
Use the general VLQ implementation for RelocInfo, rather than a custom
varint implementation. Note that this reverses the tagging logic (from
end bit to continuation bit) as this is more efficient for small values
(that now don't need to be tagged/untagged when written/read).
Change-Id: I09283f0557f9e182b4466858a2786922affb1453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839555
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74089}
This reverts commit ebd9dcdaac.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20gcc/11378/overview
Original change's description:
> [compiler] Perform MapRef's SupportsFastArray methods concurrently
>
> We are safe to go through the native_contexts_list_ since we do it
> through IsAnyInitialArrayPrototype which disallows the GC. Furthermore,
> we read that list with an acquire load which guarantees that the fields
> have been initialized.
>
> Bug: v8:7790
> Change-Id: I778d51f4ead44e472f842693a7e9ff577d6acfe3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826541
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74086}
Bug: v8:7790
Change-Id: I4ef0056fb5ab9bd037375f67ec704f842e003283
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843360
Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74087}
We are safe to go through the native_contexts_list_ since we do it
through IsAnyInitialArrayPrototype which disallows the GC. Furthermore,
we read that list with an acquire load which guarantees that the fields
have been initialized.
Bug: v8:7790
Change-Id: I778d51f4ead44e472f842693a7e9ff577d6acfe3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826541
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74086}
We have roughly a 7x (5x on ia32) ratio between bytecode and sparkplug
code. Using this number to preallocate the buffer for the emitted code
we can avoid a few copies for larger functions.
Drive-by-fix: Make sure EnsureSpace is marked V8_INLINE
Bug: v8:11420
Change-Id: I6ec48717d2e030c6118c59f5cdc286c952ec2843
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835732
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74085}
It can happen that the {value} handle initially (when we stored its
contents into the property cell) contained a ThinString but was
subsequently patched by the scavenger to hold the InternalizedString
directly.
Bug: v8:11675
Change-Id: Ia3e5fed5bd28313b6fd2031eee0658ac4136a7ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843350
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74083}
Templatize the VLQ methods to avoid std::function overheads, and add a
few optimisations (small value fast path, split writing and tagging).
Change-Id: I840d60c972916d1a6023c8ea2a67bbd540f2d159
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839554
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74081}
Turning on V8_ENABLE_SYSTEM_INSTRUMENTATION by default has broken
node-v8 builds on Windows, tracked here:
https://github.com/nodejs/node-v8/issues/192. It looks like it is due
to the fact that Node uses pre-compiled headers, which undefines
some macros needed for the event trace APIs to work. (see
src/base/win32-headers.h)
Bug: v8:11043
Change-Id: I3a6caeaaabab59d42e14b79defb2e37efd9ad04d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2830550
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sara Tang <sartang@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74080}
This CL hardens the test facility in d8 for interface types for
the fast C API.
Bug: chromium:1201011
Change-Id: Ibfe1bb242f86b4a5edd0d195e049852430f8a2fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843344
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74079}
This is a reland of d5457f5fb7
after a speculative revert.
Additionally it fixes an issue with throwing promise hooks.
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Bug: chromium:1197475
Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74071}
Mistakenly had its set as non-atomic when it was modifying maps the
concurrent compiler could see. Since this accessor is set after map
initialization, but it is not necessary for synchronization we can set
it as relaxed write.
Bug: v8:7790, v8:11668
Change-Id: I605935e96b3da47ed6abfb6676bf14456feeeddd
Fixed: v8:11668
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839548
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74066}
This is a reland of 6124a534b2
It fixes a UAF issue in the d8 test by moving the test API object
constructor to PerIsolateData. It also fixes a crash in Chromium
caused by current usage of v8::ApiObject, which should be migrated
to v8::Value*.
Original change's description:
> [fastcall] Add support for leaf interface type checks
>
> This CL adds an IsTemplateForApiObject method to FunctionTemplate
> allowing the embedder to check whether a given API object was
> instantiated by this template without including parent templates
> in the search. It also replaces the v8::ApiObject in the fast API
> with a raw v8::Value pointer to allow use of standard C++ casts.
>
> Bug: chromium:1052746
> Change-Id: I0812ec8b4daaa5f5005aabf10b63e1e84e0b8f03
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595310
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73999}
Bug: chromium:1052746, chromium:1199900
Change-Id: I4b7f0c9e9152919dde4a1d0c48fbf5ac8c5b13d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835711
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74064}
This is a reland of df52b65dba
Skip test with variant stress-concurrent-allocation.
The test manually triggers pretenuring for allocation sites, but with
--stress-concurrent-allocation these pretenuring decisions are reset
due to low survival rate in old generation.
Original change's description:
> [test] Rework Allocation Site Pretenruing Tests
>
> - Add %PretenureAllocationSite to manually force pretenuring for an
> allocation site during the next GC.
> - Replace cctest test-compiler/DecideToPretenureDuringCompilation, which
> was not triggering the tested behaviour anymore with mjsunit test
> - Add tests for deoptimizations due to pretenuring decision changes
> during OSR.
>
> Bug: chromium:1193094
> Change-Id: I5d6c35e2914b705bf96f27051a4a286413b6fe26
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2825593
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74032}
Bug: chromium:1193094
Change-Id: I366a4a074435ebffcf2b3af84152067731cd2a5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839550
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74062}
This allows using --track-retaining-path with incremental marking
enabled. This CL will also track when an object was kept alive through
the write barrier or the RetainMaps feature.
Bug: v8:11645
Change-Id: I08ab5e500ae3580aead0c188c2caeb8f2a5f9f07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829440
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74061}
This splits up js-heap-broker.cc into
- js-heap-broker.cc: the JSHeapBroker impl, and
- heap-refs.cc: ObjectRef and ObjectData impls, as well as two
JSHeapBroker functions that closely deal with refs/data objects.
Bug: v8:7790
Change-Id: I7e097b60cdec4fd61b39d7de9752d536ac313cbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2833919
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74057}
This is a reland of c83c9590ba
Changes since revert: nothing, issue was crbug.com/v8/11666
Original change's description:
> [ic] Add a new MegaDOM IC
>
> This patch implements the MegaDOM IC setup and access. A new MegaDOM
> IC state indicates that we've seen only DOM accessors at this access
> site.
>
> This CL only adds support for DOM getters in LoadIC, other kinds of
> access will be added in follow on CLs.
>
> Still remaining TODO before shipping:
> 1. Have a mechanism to invalidate the protector
> 2. Have a mechanism to find the accessors that aren't overloaded
> 3. Use a new builtin to miss to runtime on access check failure
>
> Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
> Bug: v8:11321
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73733}
Bug: v8:11321
Change-Id: I2bec54465542b5b40c42adb6eb12b6ce72cce5bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794439
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74056}
- Add v8_code_comments to allow runtime-enabled code comments with
--code-comments
- v8_code_comments is enable by default in debug mode
- Make MacroAssembler::RecordComment helper inlineable to remove
call and check overheads when v8_code_comments = false
- Make FLAG_code_comments readonly if v8_code_comments = false and
benefit from dead-code elimination
This saves roughly 5% CompileBaselineVisit time in sparkplug
on a 5MiB JS file.
Bug: v8:11420
Change-Id: I1174ab37b4bbe1ff8880416c1f6a6e28377a962c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2824428
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74055}
This pblendw/movlhps combination has lower latency and requires less
unop than pinsrq (1 v.s. 2).
Bug: v8:11589
Change-Id: I770b0c20a286774afefbac5ef0adffe463318f21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2828871
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74049}
The plan is to use VirtualMemoryCage both for the pointer compression
cage as well as the code range in a future CL. The PtrComprCage class is
removed in favor of using VirtualMemoryCage directly.
Bug: v8:11460
Change-Id: I4e34a3db1359319e3539ede587f6a73e0af03eec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2824098
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74048}
After https://crrev.com/c/2831872 Baseline and Compare_Baseline
functions need to return proper registers as placeholders.
More details can be found on comment section of this port:
https://crrev.com/c/2830897
Change-Id: I7f91a85f9c85ce1813540b4d525f2dce5faaf279
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2836705
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74047}
Also replace the schoolbook algorithm with an optimized version
that runs about twice as fast.
This also adds infrastructure to support interrupt checks from
BigInt library code.
Bug: v8:11515
Change-Id: I5f812913697384afca98937e1fb7361b4ec22d62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773043
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74045}
We can hardcode the result and to make sure we are using the correct
offset, we now have a static_assert.
Change-Id: Ic04ce9f8e46847504d3d0a5921f55cb750f7f3ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831473
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74044}
This saves quite some code space on wasm functions, which often do not
spill any tagged values (hence the safepoints will just be empty). It
also often saves a few bytes on code that actually spills tagged values,
but not to the highest frame slots.
R=jkummerow@chromium.org
Bug: v8:11630
Change-Id: I3bd77b3afcd2cf86a92ce5b302b5aa06ec0ed223
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831873
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74043}
Port ede5e81439
Original Commit Message:
This reverts commit d16eefe0f2.
It is not correct to check for node equality during the graph
construction phase, because we can have optimizations that will combine
same nodes. So it can happen that in wasm-compiler, the inputs to
shuffle are not the same, so we canonicalize using that knowledge that
it will not be the same, and allow indices > 15. But later we can have
optimizations that combine the 2 inputs (e.g. splat of the same
constants), and the instruction selector will see that the input nodes
are the same.
R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I0d388c814dc1c45f978d749218b8120bfd53bb03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835397
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74042}
The --wasm-write-protect-code-memory flag previously enforced W^X, that
is the WebAssembly code space was either writable or executable, but
never both at the same time. With compilation in background threads
concurrent to execution in the main thread, this simple scheme is no
longer viable because the same memory page can indeed be written to and
executed at the same time. Hence, this flag is currently broken and
disabled and the code space is always writable AND executable.
As a first step towards more security, we at least want to
write-protect the code space (when not required writable by compilation
threads) but at the same time keep it always executable (because of
concurrent execution in the main thread). That is, we no longer switch
between RX and RW (W^X), but rather between RX and RWX
(write-protection only).
This CL starts to change from W^X (which was broken) to
write-protection only when enabling --wasm-write-protect-code-memory.
This is the first of two CLs, where the followup CL will fix the
feature, and this CL merely prepares and cleans up the code. In
particular, this CL changes the permissions from RW to RWX (due to
concurrent execution) and renames `WasmCodeAllocator::SetExecutable()`
to `WasmCodeAllocator::SetWritable()` (and similarly named callers) to
be consistent with that change. Since the code space is now always
executable, this CL also removes now unneeded calls to
`SetExecutable(true)` in tests.
R=clemensb@chromium.org
CC=jkummerow@chromium.org
Bug: v8:11663
Change-Id: I2065eed6770215892b81daefbddf74a349e783cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835237
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#74041}
This reverts commit df52b65dba.
Reason for revert: fails on TSan: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/36351/overview
Original change's description:
> [test] Rework Allocation Site Pretenruing Tests
>
> - Add %PretenureAllocationSite to manually force pretenuring for an
> allocation site during the next GC.
> - Replace cctest test-compiler/DecideToPretenureDuringCompilation, which
> was not triggering the tested behaviour anymore with mjsunit test
> - Add tests for deoptimizations due to pretenuring decision changes
> during OSR.
>
> Bug: chromium:1193094
> Change-Id: I5d6c35e2914b705bf96f27051a4a286413b6fe26
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2825593
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74032}
Bug: chromium:1193094
Change-Id: I0cd526984d467c4e1e3637ac642f630e3cffea41
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835715
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74039}
Objects that have kind() kBackgroundSerializedHeapObject also should
have been serialized.
Change-Id: I2a3f17df61477409e94b8858e720e1a2ec720091
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835709
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74037}
Port 2871e05cc3
Original Commit Message:
This is a reland of ae0752df1b
Reland fixes:
* Remove UNREACHABLE() from constexpr switch, since we don't have a
CONSTEXPR_UNREACHABLE() (it's ok, the switch is exhaustive for the
enum anyway).
* Fix IsRegisterArray trait to use public inheritance and size_t for
std::array size.
Original change's description:
> [codegen] Add static interface descriptors
>
> Add a new CRTP StaticCallInterfaceDescriptor class, which provides
> static constexpr getters for a descriptor's registers, parameter counts,
> and so on. Each CallInterfaceDescriptor subclass is changed to extend
> StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself
> extending CallInterfaceDescriptor to still provide a dynamic lookup
> where needed.
>
> StaticCallInterfaceDescriptor provides a couple of customisation points,
> where it reads its CRTP derived descriptor's static fields and
> functions, with default fallbacks where appropriate. With these
> customisation points, the definition of CallInterfaceDescriptor
> subclasses is simplified to:
>
> a) Providing parameter names (as before)
> b) Providing parameter types (as before)
> c) Optionally setting flags (like kNoContext or kAllowVarArgs) as
> static booleans on the class.
> d) Optionally providing a `registers()` method that returns a
> std::array<Register, N> of registers that may be used for
> parameters (if not provided, this defaults to the implementation
> specific default register set).
>
> Parameter registers (and register count) are automagically set based on
> the number of parameters and number of given registers, with extra magic
> to ignore no_reg registers (to reduce ia32 special casing). The
> CallInterfaceDescriptorData is initialized based on these static
> functions, rather than manual per-descriptor initializers.
>
> This allows us to skip loading descriptors dynamically for CallBuiltin
> in Sparkplug, and instead lets us use a bit of template magic to
> statically set up arguments for the calls. Any other users of statically
> known descriptors will also benefit, thanks to C++ picking the static
> methods over the dynamic methods on the base class when available.
>
> Because we can remove various virtual functions and trigger heavier
> inlining of constantly known values, binary size slightly decreases with
> this change.
>
> Note that torque-generated descriptors are changed to use the same magic,
> rather than having Torque-specific magic, for consistency.
>
> Bug: v8:11420
> Change-Id: Icc5e238b6313a08734feb564204a13226b450c22
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73996}
R=leszeks@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Id854bb901df72787ed225fc8790c3f626121ab3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2830897
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74034}
- Add %PretenureAllocationSite to manually force pretenuring for an
allocation site during the next GC.
- Replace cctest test-compiler/DecideToPretenureDuringCompilation, which
was not triggering the tested behaviour anymore with mjsunit test
- Add tests for deoptimizations due to pretenuring decision changes
during OSR.
Bug: chromium:1193094
Change-Id: I5d6c35e2914b705bf96f27051a4a286413b6fe26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2825593
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74032}
We plan to trim the size of safepoint entries, to avoid emitting
completely empty entries, and also saving some bytes by removing
trailing zeros.
This CL prepares that by removing the assumption that the safepoint
entry contains one bit per stack slot. Instead, we just use all bits
that are there in the safepoint entry when iterating compiled frames.
R=jkummerow@chromium.org
Bug: v8:11630
Change-Id: Ib335a34da92a08e28fe84fb74f50c8535c2f4c41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831484
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74031}
This is a reland of dcd91455fd
This CL fixes two more tests that were uncovered by the
non-concurrent marking bot.
Original change's description:
> [heap] Do not scan main thread handles when starting marking
>
> We do not need to scan main thread handles when starting incremental
> marking. This reduces the time to start incremental marking.
>
> Bug: v8:11645
> Change-Id: Ib99a13e7875f50fbfe5346ac0e186d8960ea1337
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826124
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73994}
Bug: v8:11645
Change-Id: Id5b9dd0dcec08b6888a885b4f02783f674af90fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831879
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74029}
Rename
- InterpreterEnterBytecodeDispatch to InterpreterEnterAtBytecode
- InterpreterEnterBytecodeAdvance to InterpreterEnterAtNextBytecode.
The reason for renaming is consistency with baseline trampolines that
have similar functionality, but the old names didn't fit for baseline
very well.
Change-Id: I35897972fdd71f3bb0db74820db2b9034144a3c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2830794
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74027}
This changes the interaction between {NativeModule} and
{WasmCodeAllocator}. The {WasmCodeAllocator} is a field of
{NativeModule}, and only called directly by the {NativeModule}. So far,
there were two mutexes involved, the {allocation_mutex_} in
{NativeModule}, and {mutex_} in {WasmCodeAllocator}. This caused
problems with lock order inversion.
This CL thus merges the two mutex, by always locking the mutex in
{NativeModule} when calling a non-atomic method in {WasmCodeAllocator}.
This serializes slightly more code, but none of this should be
performance-critical.
This removes the awkward {OptionalLock} class and adds the "Locked"
suffix to a few methods to document that those can only be called
while holding the allocation mutex.
R=jkummerow@chromium.org
CC=dlehmann@google.com
Bug: v8:11663
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.v8.try:v8_linux_arm64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Change-Id: I8895d61fef23a57b218e068532375bac941a5a77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831477
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74026}
Makes ExternalRefEncoder work even if no isolate is available,
by separating V8 builtin external references from isolate dependent ones,
and making the first set available without providing an isolate.
This is used when disassembling external references in wasm functions.
Bug: v8:11373
Change-Id: I9a177618185a6e5612182bcb02be7cc1978e8f34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2799511
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Daan de Graaf <daagra@google.com>
Cr-Commit-Position: refs/heads/master@{#74025}
The mechanisms don't interact well. NodeObserver assumes synchronous
compilation that finishes within the ObserverNodeScope. One could
ensure all relevant lifetimes (of the NodeObserver itself, and all
captured pointers) exceed that of all spawned jobs, but simply
disabling the additional concurrent job in these cases is a
pragmatic fix for now.
Bug: v8:11658
Change-Id: I41b2f96f0166b661cf0cca94ef809ca99475e420
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2833915
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74022}
This reverts commit d16eefe0f2.
It is not correct to check for node equality during the graph
construction phase, because we can have optimizations that will combine
same nodes. So it can happen that in wasm-compiler, the inputs to
shuffle are not the same, so we canonicalize using that knowledge that
it will not be the same, and allow indices > 15. But later we can have
optimizations that combine the 2 inputs (e.g. splat of the same
constants), and the instruction selector will see that the input nodes
are the same.
Bug: v8:11542,chromium:1199662
Change-Id: I21c175f4707708038710147f64d687d1b14c6ecc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829986
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74017}
This reverts commit 6124a534b2.
Reason for revert: On suspicion of blocking V8 roll: https://ci.chromium.org/ui/p/chromium/builders/try/win10_chromium_x64_rel_ng/839568/overview
Original change's description:
> [fastcall] Add support for leaf interface type checks
>
> This CL adds an IsTemplateForApiObject method to FunctionTemplate
> allowing the embedder to check whether a given API object was
> instantiated by this template without including parent templates
> in the search. It also replaces the v8::ApiObject in the fast API
> with a raw v8::Value pointer to allow use of standard C++ casts.
>
> Bug: chromium:1052746
> Change-Id: I0812ec8b4daaa5f5005aabf10b63e1e84e0b8f03
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595310
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73999}
Bug: chromium:1052746
Change-Id: Ic99ec616310f0f75800c3dad393b5d2d685b76ab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829988
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74016}
When the enumerability flag is flipped we need to invalidate the
prototype info.
Bug: chromium:1163499
Change-Id: Iceeaa5fc47eebfe7d333c9eb594bf0763e6cef92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831871
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74013}
