StoreDataView with no args should store NaN, not zero.
Bug: v8:7700
Change-Id: I9688465fea2ac1a88f0bff2a7b7d1c419dc7e43e
Fixed: chromium:1403743
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127165
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85060}
ToBoolean was wrong for a couple of root heap numbers (namely, NaN,
holey NaN, and minus zero.
Fix this, and add an exhaustive test of root constant ToBoolean values.
Bug: v8:7700
Change-Id: I6939c6eb5130cb8a3a4f7007b1a0a1dcc415e8b2
Fixed: chromium:1403740
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128524
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85058}
When internalizing external strings, a new internalized external string object is allocated if the string is not in-place internalizable. This newly allocated strings external resource is set to null (the actual resource will be transferred by MakeThin to ensure unique ownership of the resource).
We need to preserve the original string in the InternalizedStringKey for
the second lookup (inside the critical section), as we need to access
the external resource in case of hash collisions to check for equality.
Bug: chromium:1402187
Change-Id: I62b637859b06f05d1b34cb26495f08ec44d2f2db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128089
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85057}
This histogram should give us information on which compilation methods
get used in the wild.
R=clemensb@chromium.org, mlippautz@chromium.org
Change-Id: I6906580c1b8df7a1dff9ce6c169c6861936857d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128555
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85056}
The {madvise} call should typically not fail.
There are only two errors specified (EINVAL and ENOMEM), both of which
would only happen for invalid parameters.
Thus add a CHECK that the {madvise} call does not fail.
R=mlippautz@chromium.org
Bug: chromium:1403519
Change-Id: Ib8c7ca9bbcab921b89305f1614319ecaddd79812
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4124534
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85054}
This reverts commit 84e470845a.
Reason for revert: Breaks TSAN stress-incremental-marking: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/10433/overview
Original change's description:
> [wasm][capi] Optimize all functions before serialization
>
> The existing implementation of `serialize` in the C-API is to produce
> a snapshot of the current state of the `NativeModule`. However, so far
> all users of `serialize` did not care about the runtime of `serialize`,
> but cared about `deserialize` starting up fast.
>
> With this CL all functions of a module get tiered up to TurboFan before
> serializing the module.
>
> R=clemensb@chromium.org
>
> Change-Id: Icaef846e33509d90b38559c0b689f798d35a98db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4129495
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85052}
Change-Id: Ie0758b32ef3469fe75d3a45bc3e6950b3b192edb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4131634
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85053}
The existing implementation of `serialize` in the C-API is to produce
a snapshot of the current state of the `NativeModule`. However, so far
all users of `serialize` did not care about the runtime of `serialize`,
but cared about `deserialize` starting up fast.
With this CL all functions of a module get tiered up to TurboFan before
serializing the module.
R=clemensb@chromium.org
Change-Id: Icaef846e33509d90b38559c0b689f798d35a98db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4129495
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85052}
... required for U16_NEXT in builds with ICU.
Change-Id: I2ccda0c3fa7fd0139745e6233c6ab4a5dec46b50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128520
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85051}
Which is needed to filter tests in the testrunner.
Change-Id: I6ef24ac3e7a716329acb3e860872d5c83f7d84d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128521
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85050}
TurboAssembler::Switch considers its "condition" input is 64-bit.
However, Maglev's inner integers are rather Smis/32-bit integers.
Because we didn't not sign-extend the condition before calling
TurboAssembler::Switch, negative values were treated as positive
rather than negative.
Fixed: chromium:1403749
Bug: v8:7700
Change-Id: I78e934045330012186dc83dea0dc620ec977380a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128080
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85049}
Inline {GetCodeLocked} and {ResetCodeLocked} to make the code simpler
and more efficient.
Drive-by: Make {FindJumpTablesForRegionLocked} private.
R=ahaas@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Change-Id: Id0649924440737f3a04dbb536bd2141732f4f3bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4123535
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85048}
`CpuProfiler::StopProfiling()` return `nullptr` if no profiling is
active. Thus a `nullptr` check is needed before serializing the profile
returned by `CpuProfiler::StopProfiling()`.
R=clemensb@chromium.org
Bug: chromium:1394663
Change-Id: I364eeb1d9bd670de5179e242c4462f0fbfc9c607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4126234
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85047}
The condition to pass to CheckPageFlag was inverted on arm64 compared
to x64/ia32/arm. This caused a bug in Maglev (fixed in
https://crrev.com/c/4128556), and seems like it could easily cause
other bugs in the future.
With this CL, CheckPageFlag now behaves similarly on arm64 and
x64/ia32/arm.
Change-Id: Ib6b7f157db08d2e771ceb450ab16344c3578c546
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128518
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85044}
.. which should result in 0 if x is non-negative, and -0.0 otherwise.
- Fix two invalid modulus-related folds.
- Handle aliased inputs in Int32ModulusWithOverflow.
- Drive-by: rename left/right to lhs/rhs to match the algorithm
description.
Note there is no deopt loop here since a result of -0.0 will update
feedback to kSignedSmallInputs.
Bug: v8:7700
Change-Id: I84fca0e43ded152d3520cbe73cc43299ff1c4230
Fixed: chromium:1403575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128081
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85039}
.. print them as '-0.0' instead of '0.0'.
Change-Id: I425d78e245868e7ff878c07282a0f9d8ca67a8d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128558
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85036}
The arm64 version of GeneratorStore was using the write barrier
incorrectly, triggering it when it shouldn't be triggered (and
vise-versa), and a "PointersFromHere" was mistakenly used instead of a
"PointersToHere".
The reason for the incorrect ne/eq used in CheckFlags is that this
function works a bit differently on x64 and arm64, cf their
implementations:
- x64: https://source.chromium.org/chromium/chromium/src/+/main:v8/src/codegen/x64/macro-assembler-x64.cc;l=3425;drc=605e46479aca3449a6ba1350a1de7927c76b86ad
- arm64: https://source.chromium.org/chromium/chromium/src/+/main:v8/src/codegen/arm64/macro-assembler-arm64.cc;l=3248;drc=dc950c32bd5262d66d845d2bfeb1ff4a17a857bc
For an example of both of those functions used for similar purposes,
see `MacroAssembler::RecordWrite` in macro-assembler-x64.h and
macro-assembler-arm64.h: the former uses `zero` in `CheckFlags`, while
the latter uses `ne`.
When --stress-maglev and --verify-heap were enabled, this mistake was
causing a crash in the heap verifier in the
`mjsunit/es6/typedarray-from.js` and `mjsunit/wasm/gc-js-interop.js`
benchmarks. I was able to reproduce those crashes on x64 by replacing
the "not_equal" in CheckFlags by "equal".
Bug: v8:7700
Change-Id: I42316931fba858433317238fc42f7c33985f46ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128556
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85035}
Addresses two potential performance regressions introduced in
https://crrev.com/c/4116776. First, the left-over CHECK is changed to a
DCHECK. Second, calling `EarlyGetReadOnlyRoots` should at least be as
efficient as `GetReadOnlyRoots` before the earlier change.
Bug: v8:13466
Change-Id: I93e9c06ce651cae90e9c969e54ec73e4eab80fd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127159
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85032}
This makes js-fuzzer use %OptimizeMaglevOnNextCall in 30% of the
times when optimization patterns are chosen. Other probabilities
of the function-call mutator are tuned a bit to keep using
%OptimizeFunctionOnNextCall proportionally similarly to before.
(~ some round number preferences... exact choices might not matter
much, since the original probability choices are rater arbitrary
anyways)
Bug: v8:7700
Change-Id: I7727ea27fd956efab6fbee2b4a090213d1d7ff05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4124118
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85031}
Rename the flag in order to avoid confusion with `V8_STATIC_ROOTS_BOOL`.
The flag is used by `./mksnapshot` to generate a new static-roots.h
file.
Bug: v8:13466
Change-Id: Ieb5af89b9839673fd2b8aeef197c104aa3c580aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111933
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85030}
The Sub macro sometimes needs a scratch register when the 2nd operand
is too large to be encoded in the instruction. The prologue was
already reserving 2 scratch registers, which made Sub crash on a
DCHECK when trying to reserve one more scratch register.
Bug: v8:7700
Change-Id: I995689b8b16e3ef216641f0b6cadbf58f7f3740b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128554
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85029}
When the interrupt_budget is exhausted, Maglev code calls into runtime
for tiering logic in TieringManager. As always, the runtime call
itself has a certain (noticeable) overhead.
This CL is an optimization based on the observation that the
TieringManager only performs simple bookkeeping if the
tiering_state (or osr_tiering_state) is kInProgress. We can avoid
the runtime call overhead in this case. Changes are:
1. Extract the interrupt check (= stack check) into generated code s.t.
it's separate from tiering logic. Note, combining the interrupt
check and tiering logic was a previous optimization to reduce
generated code size, introduced in crrev.com/c/3049076.
2. Skip the runtime call to Runtime::kBytecodeBudgetInterrupt if
`tiering_state == kInProgress || osr_tiering_state == kInProgress`.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
Bug: v8:7700
Change-Id: Ibcd416aaea7abdd087741551fa213fa033fe12e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127157
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85028}
A recent CL refactored some Deopts
(https://chromium-review.googlesource.com/c/v8/v8/+/4120575), and
mistakenly wrote EmitDeoptIf (which isn't an existing function)
instead of EmitEagerDeoptIf, which broke the Arm64 build (which
isn't covered by the bots yet).
Bug: v8:7700
Change-Id: I1301a26584bd76d1a2608c37c07c58fe990446d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128095
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85026}
.. and several other minor changes (branch hints, moving code around
for better grouping, const).
Bug: v8:7700
Change-Id: Ia07aa478a5ae5d1852e4ad2dce39f42743376e65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128096
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85025}
.. that should now be a jump to `no_code_for_osr` since
AttemptOnStackReplacement is now emitted in deferred code and may thus
no longer fall through.
Fixed: chromium:1403135
Bug: v8:7700
Change-Id: I3dcd7696dc5a19a0cd955b2eef1538c07b2d6e00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4124200
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85022}
Mark rhs as clobbered since we may negate it. Negate the lhs in rax.
Bug: v8:7700, chromium:1403470
Change-Id: I9a26de78fcd8d1db90c1d26617001c0c699c350e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110814
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85021}
As a drive-by this also fixes property load from smi. We still need to check that we actually have a smi...
Bug: v8:7700, chromium:1403280, chromium:1403323
Change-Id: I3c4f050b94550b8d7e4e65f733f9c1dad47941d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120575
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85015}
Even if we have a constant load, if the map is not stable, we cannot
guarantee that the load is preserved across side-effecting calls.
Fixed: chromium:1403324
Bug: v8:7700
Change-Id: Ib900cf7574711115439e6521ed8cfaa866525e78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4123532
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85014}
It's possible that various branches merged already with a value that's
in a liveness hole, but we only figure out later. If so, drop the merge
as well.
Bug: v8:7700, chromium:1403399
Change-Id: Ifd97e0c1959ffe51017e400fb028041047885a9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111932
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85013}
Many locations use the generic GetReadOnlyRoots() function to get access
to read only roots. Prominently this happens in Object::IsUndefined and
friends. The function is quite inefficient on shared read only root
build configurations as it always has to check if the shared read only
heap is already initialized or not. However, the heap is only
uninitialized during bootstrapping.
This CL replaces the branch by a CHECK and deals with the fallout
twofold. First, the SoleReadOnlyHeap is initialized earlier, right
after all heap objects have been created. Second, any location that
calls GetReadOnlyRoots() during initialization is fixed to access
the isolate-local read only roots table instead of the shared one.
Bug: v8:13466
Change-Id: I03e3e68eeefc8651818700629f69ff6163ceb6ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4116776
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85012}
