Because the Immediate might not fit in an immediate.
Bug: v8:7700
Change-Id: Ie5efca4af40cc4b10766144a295046f99cb5f25c
Fixed: chromium:1412730
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224462
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85690}
We should use consistently macro instructions in arm64
(instruction starting with a capital letter). To avoid
issues like https://crrev.com/c/4224931
Bug: v8:7700
Change-Id: I8f64c1b305ee14332ac85e8be71357a2f99c6442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224460
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85688}
`MacroAssembler::B` registers its labels with the veneer pool, while
`Assembler::b` doesn't. This meant that our JumpIf (used in particular
for deopts) could run out of jump distance.
As a drive by, also limit the maximum number of deopts according to the
limit set by the deoptimizer. This turned out to not be the issue, but
we should also do it.
Bug: v8:7700
Change-Id: Ic5a8dd3b69c995375d7caab008f31ae91d9c732d
Fixed: chromium:1410080
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224931
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85686}
This updates the (experimental, unsafe, non-standard) ref.cast_nop
to take the same immediate as the new ref.cast.
This is being done in order to align with Binaryen, per discussion
in https://github.com/WebAssembly/binaryen/pull/5473.
Bug: v8:7748
Change-Id: Ifcd2bab95a1601406370939301a5c6dfd854347c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224632
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85685}
The conflict with --future causes tests that enable experimental
features to fail if the test configuration enables --future, and the
conflict with --fuzzing makes it impossible to reproduce issues in
Clusterfuzz as it always adds --fuzzing to the commandline.
Change-Id: I7d952fc5c09967386e06d992b4dbd6129ea404c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224454
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85684}
ActiveSystemPages uses std::bitset internally for convenience. Our
MemoryChunk fields implicitly assume that all fields only require
system pointer alignment.
However MSVC on 32-bit uses uint64_t internally to implement
std::bitset. Because of this ActiveSystemPages needs 8-bytes alignment
on 32-bit architectures. We can solve this by moving
ActiveSystemPages out of the page header and storing it in the
malloc()'ed heap.
Bug: v8:13716
Change-Id: Iecb17372d065c612bbdbca7d854c76d3256bc01d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4223005
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85681}
With the recent introduction of unicode sets (v-flag), nested character
classes are allowed in regular expressions.
We always expect a nested class to be of type
`RegExpClassSetExpression`, but the empty nested class was not handled
correctly.
Bug: v8:11935, chromium:1412942
Change-Id: I3b644c8627d8fc6b320a419216372810e8003983
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224311
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85680}
We DCHECK in the scavenger that evacuated objects are not allocated
on evacuation candidates. This DCHECK fails however when
shortcutting ThinStrings to the actual string object when
incremental marking is enabled in the shared heap.
We fix this by disabling shortcutting of strings when shared
incremental marking is enabled. We already do this for incremental
marking in the local isolate.
Bug: v8:13267, chromium:1412643
Change-Id: I2a61028ae5377c7621b917ed332e15d6b25b80ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219781
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85677}
Since this is a generated file everyone should be able to update it.
Bug: v8:13466
Change-Id: Ia769bc82d6d5fdd6638763ef5330fe6aefbaf8c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221698
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85676}
Global handles processing could not actually restart marking anymore.
Weak handles are either reset or already point to live objects. This is
different from the scavenger that actually needs to update the
forwarding pointer for live objects. Move the phase to clearing of
references instead.
Bug: v8:12612
Change-Id: I21f1ba468f257990d23a129f24d5496c38c4eb04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224151
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85674}
- Move CppHeap code into scopes
- Move class declarations out of inline header
- Add TODO for working global handles processing
Bug: v8:12612
Change-Id: I97737d4f5ded940f0145ba093963f45338d44d57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221701
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85673}
Yet another access to the markbits on the r/o pages that was overlooked
in https://chromium-review.googlesource.com/c/v8/v8/+/4212397.
No-Tree-Checks: true
No-Try: true
Bug: v8:13717
Change-Id: I682a2604512dfda00b3f69d0e1f60edd66391687
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221702
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85672}
As part of https://crrev.com/c/4200642 loop peeling was enabled for
loops containing a getCodeUnit instruction.
As a side effect this also affected loop unrolling now only happening
if getCodeUnit was used in the loop body which is fixed by this
change.
Bug: chromium:1412781
Change-Id: I60e3a524340cfbdb907ae2ee5b46cbb6f514775c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219103
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85671}
Shared Large Object Space was added with the introduction of shared
space, but it was never swept.
Besides leaking memory, this led to issues as mark bits were never
cleared and object bodies not re-visited. If the map of an object changed, we would miss visiting potentially newly introduced pointer fields (e.g. SeqString -> ExternalString), freeing EPT entries that were still in use.
Bug: v8:13267, chromium:1407167
Change-Id: Id7bea2ebfbc5a4d935af4b97b7474d64d609a95d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221578
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85669}
These tests are unsuitable for "stress concurrent allocation" mode,
because it triggers GCs that interfere with the execution of
FinalizationRegistry cleanup tasks or with the clearing of WeakRefs.
Bug: v8:13257
Bug: v8:13713
Change-Id: Id43d95b53d3f68f1f70ad6ee9ff8e08e70007d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221575
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85668}
Experiment to see if this resolves a particular regression.
Bug: chromium:1407581
Bug: v8:13466
Change-Id: I45d68a14fab43775fae65dbe710d24db504f5486
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218393
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85667}
Previously, we printed the message in RunShell, which meant that it was
only visible if d8 was running in interactive mode. Now we print it
earlier so that the message is also printed when d8 executes a .js file.
Change-Id: Icdadbe5eee7400aaa843b747e3374bda41e360b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224014
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85666}
Markbits on read only pages are initialized BLACK and never change. For
any practical purposes they are unused.
This CL prevents any access to the markbits of these pages. This is a
precursor to removing them entirely from the page to make room for
static roots.
Bug: v8:13466
Change-Id: I61d3f6d9bbca750d0f34475859b34ff44f7fec1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212397
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85665}
This reverts commit 656c74218f.
Reason for revert: crbug.com/v8/13715
Original change's description:
> [liftoff] Combine "InitMerge" with the actual merge
>
> "InitMerge" did compute the state at the merge point, and a following
> "MergeStackWith" or "MergeFullStackWith" would then generate the code to
> merge the current state into the computed state.
> As every "InitMerge" is followed by an actual merge, we can combine the
> two and save one iteration over the two states.
>
> The only change in generated code is that we initialize the merge state
> after a one-armed if from the if-state instead of the else-state. This
> could potentially make the if-branch slightly cheaper and the
> else-branch slightly slower, but will not negatively impact overall code
> size.
>
> This CL should save roughly 2% of Liftoff compilation time.
>
> R=dlehmann@chromium.org
>
> Bug: v8:13565, v8:13673
> Change-Id: Id323a15e7fd765727f46830509fbaf7f5498c229
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203380
> Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85616}
Bug: v8:13565, v8:13673, v8:13715
Change-Id: I5342833aaa9c8665a514b3702eaf783d512dfa5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4222633
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85659}
Port 81aa89592b
Original Commit Message:
Known-pointer decompression used to be distinct from any-tagged-value
decompression, since the latter used to detect Smis and decompress them
with sign extension. However, we got rid of this distinction when we
introduced Smi-corrupting loads (allowing the top 32-bits of
uncompressed Smis to be undefined), which means that the TaggedPointer
and TaggedAny decompression is now identical.
We can remove a bunch of duplicate code by removing this distinction.
R=leszeks@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ib741905e09c929806cf3f584c356a4a5187df270
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221514
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#85658}
The last CL miscalculated the address of Isolate object. We should find the thread_local base address using `_tls_index_`. And, instead of calculating the address manually, all the location information is already available in `Location`. So, we can simply use the Location object to create a typed object.
Also, adding a testcase for `curisolate()` function.
Bug: v8:13394
Change-Id: I1da55bdf43a3b6100d141917eb97a1793939dca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4220104
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#85654}
After a MinorMC we iterate over the set of young external strings,
finalize the unmarked ones, and clear their slots.
Since MinorMC no longer updates the young string set (to avoid iterating
over the set during evacuation) it may now contain an old string.
If after promoting an external string from young to old, we get another
MinorMC cycle before we get a full GC (that will "reset" the young and
old string sets), the next MinorMC cycle may treat the promoted string
as unreachable. This is because the string is in old space are is
therefore left unmarked.
Bug: chromium:1412669, v8:12612
Change-Id: I1cacc25b74d9d3dd221c0cc1f0d8b4c4eb83a04d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219106
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85653}
This is a reland of commit 0d4200055b
gn complained about headers that are only included behind the
v8_use_perfetto build flag. Added "nogncheck" to suppress this
warning.
Original change's description:
> Reduce build size when building with Perfetto SDK
>
> Building Chromium with full Perfetto SDK included increases build time
> significantly. We can reduce this overhead by including only those
> parts that are required. See b/266913150 for context.
>
> Change-Id: I0cde5cb7df7b6151ec686e993488d8467c416fac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212390
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
> Cr-Commit-Position: refs/heads/main@{#85603}
Change-Id: Ifdcc9983230b5e7bab5f66a37f193d2cee698400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221573
Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85650}
This reverts commit 2e357c4814.
Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Clusterfuzz%20Linux%20MSAN%20no%20origins/33231/overview
Original change's description:
> [wasm-gc] Introduce wasm null object
>
> We introduce a wasm null object, separate from JS null. Its purpose is
> to support trapping null accesses for wasm objects.
> This will be achieved by allocating a large payload for it (larger than
> any wasm struct) and memory-protecting it (see linked CL). The two null
> objects get mapped to each other at the wasm-JS boundary.
> Since externref objects live on the JS side of the boundary,
> null-related instructions in wasm now need an additional type argument
> to handle the correct null object.
>
> Bug: v8:7748
> Change-Id: I06da00fcd279cc5376e69ab7858e3782f5b5081e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200639
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85648}
Bug: v8:7748
Change-Id: Ie53febf49b946217e0057959c757d811a97ca1eb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219105
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85649}
We introduce a wasm null object, separate from JS null. Its purpose is
to support trapping null accesses for wasm objects.
This will be achieved by allocating a large payload for it (larger than
any wasm struct) and memory-protecting it (see linked CL). The two null
objects get mapped to each other at the wasm-JS boundary.
Since externref objects live on the JS side of the boundary,
null-related instructions in wasm now need an additional type argument
to handle the correct null object.
Bug: v8:7748
Change-Id: I06da00fcd279cc5376e69ab7858e3782f5b5081e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200639
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85648}
Known-pointer decompression used to be distinct from any-tagged-value
decompression, since the latter used to detect Smis and decompress them
with sign extension. However, we got rid of this distinction when we
introduced Smi-corrupting loads (allowing the top 32-bits of
uncompressed Smis to be undefined), which means that the TaggedPointer
and TaggedAny decompression is now identical.
We can remove a bunch of duplicate code by removing this distinction.
Change-Id: Id66671497d63ed885f9e537494c011317dfd4788
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221398
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85647}
When folding constants in the MachineOperatorReducer, we should be
careful that arithmetic instructions producing int64 outputs aren't
replaced with booleans represented as int32.
Fixed: chromium:1407384
Change-Id: Ib536a53084b12bbb205308c642ee32c0f2e1e418
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219023
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85646}
This flag, together with the DEFINE_EXPERIMENTAL_FEATURE macro, allows
declaring features as "experimental", implying that they are expected to
contain bugs and are not yet ready for fuzz testing for example.
Change-Id: I1288b6c2d28ef20d19d388bf56c57c44a25ba19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181025
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85645}
