Fix a non-terminating recursive call in BitwiseAnd/Or/Xor to instead
perform the truncation + bitwise op directly.
Also, fix up Generate_BitwiseBinaryOpWithOptionalFeedback to allow
passing in optional feedback. This is a drive-by from attempting to fix
the above issue by calling Generate_BitwiseBinaryOp.
Bug: v8:9407
Change-Id: I2f91779de5533d1911b408f80664a4c9ae5c7342
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111545
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84900}
EmbedderRootsHandler is still supported.
Bug: v8:13207
Change-Id: I91107a2ed8c9603b77ae3e487f396c9ba32f3f95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111523
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84899}
... where scratch scope is no longer active and the registers
could be clobbered.
Bug: v8:7700
Change-Id: I366312e2cafd732199b4668fd5f40363688c8a04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4107089
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84897}
This CL handles the conversion from Float64 (MinusZero) to Word64 in
the representation changer.
In the original CL, the range of Numbers eligible for optimization was
incorrectly set to Integral32OrMinusZero. This CL narrows it down to
Signed32OrMinusZero or Unsigned32OrMinusZero (but not the union).
Bug: v8:9407, chromium:1400897
Change-Id: I0f09eb512e77b145b081ad5d52ca03f61d49dc62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110761
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84896}
Oilpan young generation currently remembers all weak callbacks to be
processed on each GC. This is needed to support UntracedMembers in the
old space. If the old object with UntracedMember (e.g.
ActiveScriptWrappableManager) holds a pointer to a young object, the
custom weak callback must be reexecuted on each minor GC, because the
custom callback is responsible for clearing UntracedMembers.
This is not necessary for weak containers. They hold WeakMembers, for
which we issue the regular write barrier. The CL distinguishes between
callbacks for weak containers and for custom objects. This aims to
speeds up weak processing, which currently may take >10ms.
Bug: v8:13475
Change-Id: I6964a6835dc84febddbefb5e2952d57f108d1232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080470
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84895}
This CL implements a new %CheckTurboshaftTypeOf(e, type_string)
intrinsic allowing tests to express that the expression e is supposed
to have the turboshaft type expressed by type_string eventually during
lowering.
Test that use this intrinsic are verifying implementation details and
are thus somewhat brittle and potentially platform depedent. This
intrinsic is not supposed to be used broadly, but rather to write
some tests that check the precision of turboshaft's new type system.
This intrinsic may be removed once the type system is shipped and gets
coverage in other ways.
Bug: v8:12783
Change-Id: I4cc2582273f3d668601a3203c400a8461b470cac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061889
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84894}
... and any other node needed to test it.
Bug: v8:7700
Change-Id: Ia37fdcb1db3b6fb986f026696454d443236d011c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111600
Reviewed-by: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84893}
For asm.js functions, the script name is used as the `source_url` for
code logging. If the script name was undefined, as it can happen for
asm.js code that gets evaluated in an eval, then `nullptr` was used
as the `source_url`. The problem was, the logging code accessed
`source_url` unconditionally, which caused a segfault.
With this CL the empty string is used as `source_url` instead of
`nullptr`.
The test revealed another problem in the isolate mode: profiling has
to be stopped and the profiler disposed before the isolate dies.
R=clemensb@chromium.org
Bug: chromium:1395401
Change-Id: Ia9730bb033a22b799ea2b1903ea540db9f259513
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079685
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84892}
Rolling v8/build: 3d4b0c1..c72e275
Rolling v8/buildtools: 202b660..80c045e
Rolling v8/buildtools/linux64: git_revision:70d6c60823c0233a0f35eccc25b2b640d2980bdc..git_revision:5e19d2fb166fbd4f6f32147fbb2f497091a54ad8
Rolling v8/buildtools/third_party/libc++/trunk: 5239965..2948540
Rolling v8/buildtools/third_party/libc++abi/trunk: 25a3d07..123239c
Rolling v8/buildtools/third_party/libunwind/trunk: 09a1f53..5e22a7f
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2f1cf61..c6c2247
Rolling v8/third_party/depot_tools: a964ca1..5decb17
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20221209.0.1..version:11.20221213.1.1
Rolling v8/tools/clang: 3344dd8..7356f69
Change-Id: I2c8919fd71e138733ec8b793f36cea37b8c984e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111704
Commit-Queue: Liviu Rau <liviurau@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84891}
My recent change https://crrev.com/c/4071249 caused some slowdowns when
using Maglev. This change is an attempt to improve the speed of encoding
translation arrays by:
1. not converting signed values to unsigned (base::VLQConvertToUnsigned)
until after we've finished comparing the value to the previous value
and determined we need to write the value into the result array,
2. comparing only used operands, not all five possible operands (some of
which were guaranteed to be zero), and
3. calling ZoneVector::push_back directly rather than using
base::VLQEncodeUnsigned for cases where a value is known to be
representable in a single byte (opcodes and register numbers).
I don't have great faith in my benchmarking results, but this seems to
decrease time in V8.TFCodeGeneration by 3-5 ms on Octane.
Bug: chromium:1396229
Change-Id: I0e5714ef5e499ec64369414fb336fa1462d99164
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4086125
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84887}
This reverts commit fffae64444.
Reason for revert: Causes failures since an isolate in state
TEAR_DOWN might still park itself.
Original change's description:
> [heap] Ignore client isolates that are tearing down
>
> Client isolates that tear down only participate in the safepointing
> protocol to remove themselves from the list of all clients without
> blacking global safepoints.
>
> However, we do not need to consider them for the root set since such
> isolates will just detach as soon as possible and therefore are not
> allowed to touch the shared heap anymore anyways.
>
> This fixes a heap verification bug where heap verification fails for
> an isolate that tears down fails because the external string table
> was already finalized.
>
> We also can't move external string table finalization after detaching
> since then we would have races on the shared external pointer table.
>
> Bug: v8:13267, chromium:1401078
> Change-Id: I7d97c2d223bd87f620d9a92a9266be7b88afd9c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110857
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84870}
Bug: v8:13267, chromium:1401078
Change-Id: I0c9fb1adad850b834a79cb64e535051c30762397
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112005
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84886}
The location I added this in is wrong as it inherits the flag state
from VERIFY_PREDICTABLE, which I did not intend. This patch moves
the location earlier so that it doesn't pick up state from other
flags.
Bug=v8:13477
Change-Id: I23df7e778690e8b9f588cd2ce3db318c5fa22cb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112146
Auto-Submit: Scott Violet <sky@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84885}
This stores the CallDescriptors used for i64 <-> BigInt conversion
builtins as process-globals on the WasmEngine, instead of creating
them as temporaries whenever they're needed.
The primary purpose of this change is to simplify the interface to
the Int64Lowering by eliminating its "special case" parameter, in
preparation for moving that lowering to a different point in the
compilation pipeline.
A minor secondary benefit is that this will save a little bit of
(repeated) Zone memory usage.
Bonus change: drop the Int64Lowering from 64-bit builds, where it
isn't used, but was compiled in up to now. This saves ~17 KiB on
Android-arm64 builds.
Change-Id: Ib35d2e0f772110652eb05abd4c42d848108164b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110898
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84884}
Simply using the AlwaysAllocateScope on threads other than the
isolate's main thread may violate DCHECKs that this scope isn't
enabled.
However, we were using this mechanism to make GC allocations less
likely to fail. This CL therefore switches to another approach where
we simply allow allocations from the GC.
Bug: v8:13267, chromium:1401180
Change-Id: I3c6a34440af3ed87a8b50707006153416b3dbf42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111642
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84882}
With lazy compilation (and without lazy validation) we will have
validated all functions when starting Liftoff compilation. Thus
validationg again during Liftoff compilation is unnecessary overhead.
This CL removes validation from Liftoff compilation, saving both binary
size of V8 and performance in the default configuration. In the unlikely
case that we did not validate before (e.g. because we run eager
compilation or lazy validation is enabled), we explicitly validate the
function body before starting Liftoff compilation.
R=ahaas@chromium.org
Bug: v8:13565
Change-Id: I08bcac755081333795d78625bf1fc8cae856f255
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092496
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84881}
HandleSlot was only checking whether the target object is in the
shared heap but that flag is only set after the GC for large pages.
This CL fixes this by also checking for SHARED_HEAP_PROMOTION.
Bug: v8:13267, chromium:1401069
Change-Id: Ie2d8b1b1557175d45cff6b27b7291b3d2c4560df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110739
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84880}
Instead of loading {kMaxUInt32 + 1} (or 2^31) as a 64-bit constant, load
{kMaxUInt32} as a 32-bit constant. This saves four bytes on debug-code
enabled builds (i.e. mostly debug builds).
R=thibaudm@chromium.org
Change-Id: I58a5fac9f94df6cb6dbc22dfc33e191765ef0622
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096738
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84879}
This unordered map is mixing code objects and other objects, which makes
operator== unsafe to call with external code space enabled. In case a
heap object and a code object have the same compressed pointer, they
will also have the same hash value and thus must be compared with
EqualSafe.
Bug: v8:13466
Change-Id: I269c46c054d8acd3accb126d2f7d3225ef4bbfde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111640
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84878}
For bigger code blocks it makes sense to use the "scoped comments" with
an opening and closing bracket. In particular, if more such scoped
comments are already generated inside the block (e.g. for decoding the
sandboxed pointer, or for AssertZeroExtended).
Thus add scoped comments around loading from memory and storing to
memory.
Drive-by: Mark the {CodeComment} constructor V8_NODISCARD so we do not
accidentally define a temporary object that dies right away.
Drive-by 2: Remove the "#undef"s at the end of liftoff-compiler.cc; we
do not support jumbo builds any more anyway.
R=thibaudm@chromium.org
Change-Id: If4af8e9f4288529e0fe176c7f0f8376474cfa469
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096737
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84876}
My plan is to add a finch flag to the chrome side. It'll be a kill
switch, but given the history with changing the implementation, I want
to make sure we have the ability to switch back.
Bug=v8:13477
Change-Id: I1559e10d134bd78699b1119be26934570c6e5241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108811
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84874}
Three issues were fixed:
* In debug state, only publish debug code.
* When entering debugging in an isolate, only delete the code of
those NativeModules that aren't in debug state already.
* When async compilation finishes, only throw away code if the debug
state changed during compilation.
Original message:
Currently V8 recompiles all functions of a WebAssembly module when a
debugging session starts. This is outdated behavior and
causes OOMs for developers. With this CL all compiled code just gets
removed when a debugging session starts, and debugging code gets
compiled lazily.
This behavior may lead to small delays whenever a new function gets
entered by the debugger. However, developers are used to debugging code
being slightly slower, and the small delays should be in the order of
few milliseconds. On the other hand, debug modules can be big,
sometimes even more than 1'000'000 functions, and developers reported
OOMs when debugging.
R=clemensb@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ie27388a287cd16a67a483e14fc22c2ab4180962e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079190
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84873}
We were doing the REPRL initialization in Shell::Initialize, which is
also executed by newly created worker threads. This would lead to double
initialization of the REPRL interface when Workers were created, which
would confuse Fuzzilli and cause it to terminate the d8 process.
This CL now moves the REPRL initialization into Shell::Main.
Drive-By: disable builtins coverage by default as it's currently broken
and move some cleanup code out of the REPRL loop.
Bug: v8:10571
Change-Id: I7627ac4d36f6a015bf34f056f31983d8d189709b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110738
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84872}
We do not collect them any more since https://crrev.com/c/4078966
(landed in v11.0), so deprecate the fields now for v11.1.
R=mlippautz@chromium.org
Bug: v8:13565
Change-Id: I6b454cd6591c6489043002226f3c4fd19fdeb7e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079227
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84871}
Client isolates that tear down only participate in the safepointing
protocol to remove themselves from the list of all clients without
blacking global safepoints.
However, we do not need to consider them for the root set since such
isolates will just detach as soon as possible and therefore are not
allowed to touch the shared heap anymore anyways.
This fixes a heap verification bug where heap verification fails for
an isolate that tears down fails because the external string table
was already finalized.
We also can't move external string table finalization after detaching
since then we would have races on the shared external pointer table.
Bug: v8:13267, chromium:1401078
Change-Id: I7d97c2d223bd87f620d9a92a9266be7b88afd9c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110857
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84870}
The destructor for BackgroundMergeTask checks that the task doesn't have
pending foreground work. However, there are valid cases where the task
can be abandoned without completing its foreground work, either because
another copy of the same script showed up in the Isolate compilation
cache or because the serialized code data had an incorrect source hash
and was rejected. This change removes the problematic DCHECK and adds a
new one in code-serializer.cc at a point where we can actually be sure
there isn't pending foreground work.
Bug: chromium:1400781
Change-Id: Idb3538229d25f297adf5b2696c4b4b50d85557b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4105926
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84869}
Adds new `br_on_cast_fail null <branch depth> <heap type>` instruction
with opcode 0xfb4b.
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: Ieb7322a31fd2b5f64a669193003a365149bef34e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4085008
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84868}
Entry frames use a dedicated (and nonstandard) slot to link to the
next exit frame's frame pointer. This slot is initialized using the
Isolate's `c_entry_fp_` field (1. we can't use rbp since it may
contain arbitrary values with -fomit-frame-pointer, and 2. V8 stack
walks skip over all C++ frames between exit- and entry frames).
This CL clarifies all this by:
- renaming EntryFrameConstants::kCallerFPOffset to
kNextExitFrameFPOffset to avoid confusion with the
StandardFrame::kCallerFPOffset constant.
- extending comments in JSEntry codegen.
- adding a static_assert as a link between the constant and related
code.
Change-Id: I38ed6d2f6f8249e0befabff5d3f3a8f95426e04c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3936278
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84867}
Building cctests without `v8_enable_backtrace = true` fails prior
to this change.
Change-Id: I85dd81f2cf52ed4c5f345e69c20a56edf7a9545a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4107088
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84866}
- More const
- A few handle-derefs less
- Faster code in debug/optdebug
Change-Id: I4aa8f5e0acd76c5021b4184effddbc70bf0fe30b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4105980
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84865}
This includes the class name of the target object as part of the
description for Proxy objects, i.e. `Proxy(HTMLElement)` for proxies
whose targets are `HTMLElement`s. This greatly improves the debugging
experience with proxies, which are becoming more common these days (for
example with Vue using proxies for their components).
Before: https://imgur.com/SbR4s6H.png
After: https://imgur.com/NWQJFj8.png
Fixed: chromium:1400253
Change-Id: I3bd2b0f91a3aeaa531d5e5dd2ca3e777e4663ba1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4109729
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84864}
Before this change, the mutation order of js-fuzzer was hard-coded
and always executed in the same order. This e.g. prevents certain
mutation interactions. E.g. in the typical V8 pattern:
%Prep(foo);foo(N);foo(N);%Opt(foo);foo(N);
This gets typically inserted by the FunctionCallMutator, but none
of the arguments N would get mutated later, since e.g. the
NumberMutator is executed earlier.
This change adds an experiment that makes the top-level mutation
flow more flexible. With a probability of 20% each we now also:
- Shuffle the different mutators.
- Run a few random extra mutators after the first round.
We annotate the output files with comments if the experiment was
chosen to easier analyze later if interesting new bugs were found.
Change-Id: I581d43b41a8e1d87ff1e8cab435a1b6e834db0f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096477
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84863}
The current version of CloneAndInlineBlock assumes that the inlined
block is a direct predecessor of the currently reduced block. With
recent Return reductions implemented in branch elimination that's no
longer the case, as we're looking one edge past the current block.
Bug: chromium:1399626
Change-Id: I2ce23672c0e33b2857a4663d8e7ad5ed1df3c20e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4097125
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84862}
The stack slot index in maglev is the offset from the frame pointer, so
it is always negative.
Storing it as an unsigned 32-bit integer causes issues when the value is
used as a 64-bit int (preventing sign extension).
Bug: v8:7700
Change-Id: I0c64fc8c96f72507f02b870155f2fe7655485894
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4107388
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84860}
When taking over large pages from another heap, allocated limits in
MemoryAllocator need to updated as well.
Bug: v8:13267, chromium:1401077
Change-Id: I2ef349578de34ff697a5fa76da17870fa171df95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108649
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84859}
This reverts commit 27c561617f.
Reason for revert: Causes some benchmarks to fail.
Original change's description:
> [d8] Do not dispose isolate in quit()
>
> With --shared-space the main isolate has to be disposed last, so we
> can't really dispose the main isolate while worker isolates are
> still running without violating our invariants.
>
> Solve this by not invoking Isolate::Dispose() for `quit()`.
>
> Bug: v8:13267, chromium:1400810
> Change-Id: Id9d6288c62d9c03d5c2f40c52efd0ac6422ac822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4106751
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84846}
Bug: v8:13267, chromium:1400810
Change-Id: I51559ffdb0bbbd870de3f33f65812cb9056636b4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110648
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84858}
marking_barrier_type_ wasn't initialized in MarkingBarrier's ctor.
With --shared-space and enabling incremental marking in the shared
heap this could lead to the load of an uninitialized value in
`is_minor` in the DescriptorArray write barrier.
The write barrier was also not using the right value for old_marked
when both minor and shared incremental marking were enabled.
Bug: v8:13267, chromium:1400730
Change-Id: Ibd682b9baba333ce16af028e4f66aefb6c8aaea7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108028
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84855}
The comparison of an external pointer used `kRef` here which is the
ValueKind for Wasm GC references. As those references are only 32 bits
on pointer-compressed builds, a 32-bit-comparison is used.
(This was introduced with change https://crrev.com/c/4016816.)
If the pointer has the 32 least signficant bits zeroed out, it assumes
that the callref target is a WasmJSFunction looking in the code table
for this index for the JS function. As it is a wasm function, it has a
trap handler registered there causing the call to trap instead.
Fix: v8:13534
Change-Id: I35474e1eaeeefff3cbe5bec9c6ede470688a0ce6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4106850
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84853}
