- 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}
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}
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}
This test produces different outputs when compiled with
gcc. It is currently failing on PPC using gcc-8, it also has
failed on riscv: https://github.com/riscv/v8/issues/174
I have also tested it with gcc-10 on x64 and it still fails.
The line numbers seem to be different when compiled with gcc
instead of clang.
As a workaround we can force the usage of macros in one line
to assure outputs are the same on either compiler.
Change-Id: I36a05d0dc62dfe66bdfcf177422836cb231284b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844666
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74162}
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}
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}
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}
This will make --regenerate_expected_files flag work for message tests.
Bug: v8:10773
Change-Id: Ica87bd69bd0a41e2a3c168d2200d0cd0c7f094da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2842387
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74127}
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}
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}
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 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}
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}
- Add filter to skip baseline handlers
- Make profiler types more readable
- Refactor tickprocessor test to use serialized symbols
- Add large tickprocessor stress test with a complete V8 log
Change-Id: Icc09c2eb8ea63c1805d793d2d47f79b0d5080b5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784686
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74094}
This CL disables two more fast API calls tests that shouldn't be run
on stress_snapshot and jitless variants.
Change-Id: I2e3270ba7b93e598219b87195640675cfc4571ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843362
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74091}
Flag reads from background threads are unfortunately scattered and
hard to completely avoid in the current state of V8. An example TSAN
failure:
ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/36369/overview
The root cause is that FlagScope destruction modifies flag values on
the main thread, racing with flag reads from the background thread. In
cctests, there's no need to reset flags back to initial values at the
end of tests. Let's simply remove the problematic flag scopes.
Bug: v8:11658
Change-Id: I59ed3794ddc9ed570772726a423dc22afc4dc207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843346
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74082}
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}
