We add final types to wasm-gc.
- We introduce a `kWasmSubtypeFinalCode` as an alternative to
`kWasmSubtypeCode`.
- Behind a flag, we interpret types behind this code as final, as well
as types outside a subtype definition by default.
- For final types, type checks for call_indirect and ref.test etc. are
reduced to simple type identity checks.
Bug: v8:7748
Change-Id: Iabf147b2a15f43abc4c7d1c582f460dbdc645d66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096478
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84955}
Error mode: a TypedArray backed by RAB claims it's not backed by RAB.
Drive-by: disable resizability even harder when --harmony-rab-gsab is
not on.
Bug: v8:11111, chromium:1402139
Change-Id: I937c69f6124419cc8d29da0195686bc3b9a5c281
Fixed: chromium:1402139
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110751
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84952}
- Converts tests in EmbedderTracingTest to UnifiedHeapTest
- Move EmbedderRootsHandler tests to their own file
- Adds support for CppHeap in ManualGCScope
- Drive-by fix typo
Reland: Fix issue with attaching a CppHeap while incremental marking
is already running.
This reverts commit d90a98edc1.
Change-Id: Ifafa9145df3103578c4c7f1b3b0336b4bd9f34dd
Bug: v8:13207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110941
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84950}
ShadowRealms have a callable boundary: there cannot be any edges between
objects in the ShadowRealm and those from other realms. V8's
prepareCallStack API breaks this invariant via getFunction() and
getThis(). This CL makes those functions throw when called inside
ShadowRealms.
See also
https://docs.google.com/document/d/1aXEy4YCC9CduxLs7MGw-UOm0P4OuG7W-cScBnLG3ALI/edit?usp=sharing
Bug: v8:11989
Change-Id: I5a2b8fa735c0f10583c8cede4062645986b2d914
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108810
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84944}
All IFS values of resumable loops are loop phis, so values from before
the loop can safely be dropped. In fact, if we don't drop them we might
not be able to restore them and crash in a safety check. Eagerly
dropping the values allows us to keep the safety check.
Bug: v8:7700
Change-Id: I99ef80e35db5aba965dc1c5c9d78f1d085e589fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110940
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
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@{#84943}
Usually sharable strings are automatically promoted to shared old space
and can be shared in-place.
There are currently two exceptions:
- When using a non-moving GC (e.g. minor MC)
- Strings in LO space
Account for these exceptions by copying strings to the respective shared
space when sharing them.
Bug: chromium:1400048
Change-Id: I20713b5f32f449c14febd848e289b5767530a257
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110752
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84942}
We use 0xffffffff as a sentinel for "no supertype". Therefore we
should reject it as we parse it. We implement this by rejecting
supertypes outside V8's type definition limit.
Bug: v8:7748
Change-Id: I7942d94073d8f7350528fb0e364e91f7359c8cec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110750
Auto-Submit: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84934}
Aligning struct fields to multiples of their own size can leave gaps
between them, e.g. when i8 and i32 fields alternate. This patch
introduces a simple optimization: it keeps track of the most recent
such gap, and attempts to use it for later fields that are small enough.
Bonus changes:
- Cap field alignment to 4 bytes (because we only have 4-byte object
alignment anyway).
- Don't re-compute field offsets when canonicalizing types. Instead,
re-use the original type's offsets.
Bug: v8:7748
Change-Id: Iabfc8e7cda94f16d196ed4429f3aa92d249b3b72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092494
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84933}
This (test-only) runtime function only supported unoptimized frames as
callers. Add support for Maglev frames as well by extracting the
relevant BytecodeArray and bytecode offset.
This reverts commit 955de73ee5.
Bug: chromium:1400549,v8:7700
Change-Id: I80f80f8736ff0400d6d47e355add2a07cdc4559e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111851
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84931}
This is a reland of commit 5d95bd39ca
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Id9d1a1ab2dc36e481287a1a25863b45bf281920c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110746
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84928}
This reverts commit 5d95bd39ca.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20gc%20stress/2101/overview
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Ib82d06ab8281f0e59a2af2b631bf93b25064df1f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110745
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84925}
The problem was that synchronous Maglev OSR potentially caused
code deoptimization during compilation dependency finalization; this
led to a lazy deopt when returning from the call to
Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
is already marked as eager deopt since that's how OSR is implemented
under the hood. See also the comment in runtime-compiler.cc.
We fix this by changing synchronous Maglev-to-Turbofan OSR
behavior s.t. actual OSR compilation is triggered from Ignition
(and not from Maglev). In other words, when synchronous OSR is
requested:
1. trigger an eager deopt from Maglev to Ignition by returning a
non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
2. Ignition handles the pending OSR compile request (through
osr_urgency).
This CL also reverts previous partial fixes:
This reverts commit 21969e8e24.
This reverts commit 6bcbcfed5c.
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84922}
There was a concurrency issue `WasmEngine::EnterDebuggingForIsolate`
which gets fixed by this CL. When multiple isolates entered debugging
concurrently, then only the first CL that changes the debug state of
a NativeModule would remove all compiled code from the NativeModule.
However, changing the debug state and removing the compiled code would
not happen atomically inside a lock. Instead, first the debug state
gets changed inside the lock, and then the compiled code gets removed
outside the lock. The concurrency issue is now the following.
Assume isolate A enters debugging. It takes the lock, and then changes
the debug state. As it changes the debugging state, it is the task of
isolate A to delete all code. Concurrently isolate B also enters
debugging. It sees that the debug state is already changed to debug
state and therefore just continues execution without removing code
first. In the following execution of isolate B non-debug code may get
executed if isolate A is slow with removing the code.
This CL fixes the issue by adding a filter to `RemoveCompiledCode`, and
then letting all isolates remove compiled code according to the filter.
This means that isolate B would also iterate over all the code and
remove all functions which are non-debug functions. This guarantees
that isolate B does not execute non-debug code that existed before
isolate B entered debugging.
R=clemensb@chromium.org
Bug: v8:13541
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Change-Id: If688c7f9b15f78e6cd6898123a321e577d32365f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111524
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84919}
The previous fix from
https://chromium-review.googlesource.com/c/v8/v8/+/4086127 was
insufficient. It prevented shared objects from being optimized as
prototypes, but callers of OptimizeAsPrototype also assume that all
JSObjects can track prototype users via prototype_info on the map.
This CL attempts a broader fix where shared objects are not considered
optimizable as prototypes at all. When used as a prototype, shared
objects are treated like non-JSObjects (e.g. JSProxy, WasmObject).
Bug: chromium:1401295, v8:12547
Change-Id: I9886e9ccac9e597e7dd34a09083a096ff4e3bf16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112150
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84916}
This CL avoids unnecessary heap allocation for BigInt64 array
store/load by
- setting the output representation of a load to word64, and
- propagating word64 truncation to the source of a store.
This CL introduces a simplified operator SpeculativeToBigInt
which is applied to the source of a store to a BigInt64 array to
deopt on a non-bigint input.
Bug: v8:9407
Change-Id: I48ce13761bc4cf742d5b18cec4476dc9ad131414
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4101011
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84908}
Certain optimization phases are more convenient to write when they
can run before Int64Lowering. So this patch moves Int64Lowering
from graph building to a later point in the pipeline.
The logic itself is not changed, and no impact on performance or
behavior is expected.
Change-Id: I3597498e8f3bb9e6fa8c3b36dcfcc735440f80b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111237
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84907}
Optimize FastDtoa, in particular Grisu3. In addition to making
a microbenchmark, there are a number of smaller and larger
changes here:
- Replace divisions by power-of-ten with multiplications by
their inverses, using an algorithm very similar to the one
in libdivide.
- For DiyFp::Times(), use 128-bit hardware multiplication
if available (which it generally is on 64-bit platforms).
- Where possible, send around a pointer to the end of the string,
instead of a pointer and a length, reducing register pressure
(especially for Intel). Where not (easily) possible, add
a local variable to make the compiler understand that length
and decimal_point cannot alias.
- Change some ints to unsigneds where it helps us avoid sign
extensions.
- Some minor changes to reduce instruction dependency chains.
- Inline BiggestPowerTen().
Actual performance gain is wildly different between platforms.
On my 3990X workstation (Zen 2), gains are about 21%. On a M1
Mac Mini, they are about 17%. But on my i7-10610U laptop
(Comet Lake, so Skylake microarchitecture), the function is
78% faster. This is probably because large divisions
(divisor over 255) seem to hurt a lot on Skylake, but I haven't
gone through it in detail.
Change-Id: I5b67c257d788a3f7d1be7065d055456852451d68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110741
Commit-Queue: Steinar H Gunderson <sesse@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84906}
This CL adds subtyping support to call_indirect: signature comparison
for call_indirect will now succeed if the real signature of the table
element is a canonical subtype of the declared signature. This makes
wasm-gc semantics strictly more permissive, i.e., less programs will
trap.
Drive-by: Since liftoff call_indirect became more complex, we try to
make it a little more readable by renaming registers.
Bug: v8:7748
Change-Id: I42ba94161269e3a4535193d18bf00b3423e946bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937466
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84903}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
Since its introduction (behind a compile-time flag), conservative stack
scanning was disabled by default on tests. This CL inverts this logic,
enabling CSS by default for all tests that do not define an explicit
scope to disable it.
Bug: v8:13257
Change-Id: I5ea4249d02f69b0b1e195415c2562daf5d8c0ea9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100912
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84848}
The CL applies multiple changes:
1) Reverts back to using std::vector<> for young nodes. Distinguishing
between young and remembered nodes is still needed to allow fast
filtering.
2) Adds the has-old-host flag to TracedNode, which is used to remember a
node.
3) Adds bailouts for old objects into UnifiedHeapMarkinState and
ConservativeTracedHandlesMarkingVisitor.
Bug: v8:13475
Change-Id: Ib296ece9df6f783bb3d47ffa0794be16e6c1aea8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080386
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84839}
This CL adds support for BigIntEqual in turbofan and collects type
feedback for small BigInt equal and strict equal in ignition.
Bug: v8:9407
Change-Id: I29cbc4d3bdfe9fcde8c1717afe83654a84c25c36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096557
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84832}
This is a reland of commit 303facf5e1
This CL fixes DCHECK failures by using BasicMemoryChunk in
RecordOldToSharedSlot.
Original change's description:
> [heap] Also promote strings in large objects into shared heap
>
> With --shared-string-table all in-place internalizable strings are
> directly promoted from new space into the shared heap. However, this
> wasn't the case with large objects. This CL fixes this and adds test
> to guide fuzzers.
>
> Bug: v8:13267, chromium:1400048
> Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84805}
Bug: v8:13267, chromium:1400048, v8:13588
Change-Id: I221592ec723d2b5e92094ff2598a99576d72a677
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4098831
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84830}
Currently, any session can resume instrumentation breaks by sending
Debugger.resume command. That can lead to unreliable breakpoint
placement because sessions can resume too early.
The early resumption can happen in two ways:
- When we have two instrumented sessions, the first one to resume
can prevent the other one from setting its breakpoints
before executing the code.
- With one instrumented session and one without instrumentation
breakpoints, the uninstrumented session's Debugger.resume
command can resume the instrumentation pause before the
instrumented session can set its breakpoints.
This patch fixes both of these issues by changing the instrumentation
pause resumption logic to take note of the sessions that were notified
about the instrumentation breakpoints. The debugger will only resume
once all those sessions resume (or disconnect).
Bug: chromium:1354043
Change-Id: I84cf16b57187dbb40645b2f7ec2e08f0078539dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100466
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84827}
This CL adds v8::ArrayBuffer::NewResizableBackingStore.
This API is needed to support Mojo cross-process serialization of
resizable buffers. See https://chromium-review.googlesource.com/c/chromium/src/+/4086949
Bug: chromium:1396361, v8:11111
Change-Id: I1d3ad367f28015184fd80fd2f05a37a3659d3a66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4093555
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84826}
Asm.js code (translated to Wasm) is valid by design, do not try to
validate it.
This is achieved by fully populating the {validated_functions} bitset
for asm.js modules. To make this safe(r) we do not allow to change the
origin or a WasmModule after initialization, which requires some
refactoring mostly in tests.
R=ahaas@chromium.org
Bug: v8:13447, v8:13565
Change-Id: I174c01f13185ff4117b02882b953c6ba29a3644d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100686
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84824}
This reverts commit 303facf5e1.
Reason for revert: Causes failures with fuzzers.
Original change's description:
> [heap] Also promote strings in large objects into shared heap
>
> With --shared-string-table all in-place internalizable strings are
> directly promoted from new space into the shared heap. However, this
> wasn't the case with large objects. This CL fixes this and adds test
> to guide fuzzers.
>
> Bug: v8:13267, chromium:1400048
> Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84805}
Bug: v8:13267, chromium:1400048
Change-Id: If20528bbf804b73ce8ad10f8addc9a1f11b50d96
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4101261
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84813}
The "is there enough data" check has to be done *after* reading
maxByteLength.
Bug: v8:11111, chromium:1400431
Change-Id: I7c2eddaeb998f3cd3919e118c093a5d036fca408
Fixed: chromium:1400431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100468
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84809}
With --shared-string-table all in-place internalizable strings are
directly promoted from new space into the shared heap. However, this
wasn't the case with large objects. This CL fixes this and adds test
to guide fuzzers.
Bug: v8:13267, chromium:1400048
Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84805}
Code objects are linked in a custom per-native-context weak list of
optimized code (previously there was also a list of deoptimized code,
but this was recently removed).
There used to be reasons for this list, but at this point it is only
used by the debugger to mark code for deoptimization. The debugger can
do this with a heap walk instead, so we can remove this list and indeed
the next_code_links from Code objects themselves.
Change-Id: Iebbed4adacd31b8ddc442ae6355ea45c691cc856
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061515
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84804}
This patch moves the stop method from context group to session to enable
stopping each session independently. This is useful for testing that
stopping does not interact badly with other sessions.
Bug: chromium:1354043
Change-Id: I885cf49f2d4cf006fa5228edf2954099e45cfc6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100484
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84797}
This CL fixes two bugs:
- The monotonicity violation in the typers of ToBigIntConvertNumber and
Integral32OrMinusZeroToBigInt.
- The missing handling of conversion from Tagged output with the type
DoubleRepresentableInt64OrMinusZero to Word64.
Bug: v8:9407, v8:13580, chromium:1399951, chromium:1400053
Change-Id: I669820b52e5b82bddc9853cfd97a2361c344a2cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096990
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84793}
We already exclusively use the WasmEngine's AccountingAllocator for all
decoded Wasm modules. Except for tests, the same allocator will also be
used for validation. Thus do not pass it down explicitly, but get it
from the WasmEngine when needed.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Idaa9d6c3e0ab0051bf85bb2667accac89e8b5607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84792}
A new test added in https://crrev.com/c/4092575 times out on ASan
windows builds and is slow.
Superseeds https://crrev.com/c/4096677.
No-Tree-Checks: true
No-Try: true
Bug: v8:13466
Change-Id: I40d61459437434cf739fbff8c223871012a23010
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096817
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84784}
The current reduction of blocks that are branch targets with a known
condition assumes that this is the first time we're seeing the given
condition with the given value. That's no longer the case, so updating
the expectation accordingly.
Bug: chromium:1399627
Change-Id: Id84d80a38801cf6178b476e62160d616b948d8d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096984
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84780}
This is required to be spec-compliant.
The previously implemented behavior was more relaxed allowing one to use
`ref.cast null` on non-nullable inputs and still getting a non-nullable
result on cast success.
Bug: v8:7748
Change-Id: I1297314389b0445a7c8d5a74f37d07a723d7a133
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4091549
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84776}
This is a reland of commit 331c577e1d
Fix DCHECK for single generation builds.
Original change's description:
> [static-roots] Allow creating isolates from existing r/o snapshot
>
> This adds the ability to create an isolate from scratch, except the
> read only roots, which are initialized from a read_only_data snapshot.
> To do this we split the heap setup in a read/only part and the rest.
> The goal of these changes is to later support writing serializer tests,
> even if the read only roots are static and have to be loaded from a
> fixed snapshot.
>
> Bug: v8:13466
> Change-Id: I078695b95710e5281da013ca0c08af0e153b4725
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037271
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Olivier Flückiger <olivf@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84750}
Bug: v8:13466
Change-Id: Ic680b7620fc3176260c5d550e474412afef5f598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092575
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84773}
The previous fix was using the wrong getter for accessing the length.
It also threw an error when the created TA was length-tracking but in
bounds.
Bug: v8:11111,chromium:1399799
Change-Id: I5a94b1b49b2e30cf33999be7ff0ee8e4f5323849
Fixed: chromium:1399799
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4090984
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84771}
I originally thought MaxByteLength would only be needed for
v8::ArrayBuffer and v8::SharedArrayBuffer, but it is also needed on
v8::BackingStore.
In particular, blink uses Mojo to serialize ArrayBuffers' contents via
v8::BackingStore when doing cross-process postMessage.
Bug: chromium:1396361, v8:11111
Change-Id: I86d44829175ad760fb43294d386483a16044fc3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4090708
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84767}
Array.toReversed always creates properties even for holes, but the
optimization paths for HOLEY_* arrays did not respect the spec. This CL
fixes the fast paths to set `undefined` value instead of the hole.
Bug: chromium:1395672
Change-Id: I51584829caf312a1864f93928315782bb120ee14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4081689
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84766}
This CL introduces two JS operators JSToBigInt and
JSToBigIntConvertNumber and one simplified operator
Integral32OrMinusZeroToBigInt.
- BigInt constructors are lowered to JSToBigIntConvertNumber in the
inlining phase.
- JSToBigIntConvertNumber is replaced with
Integral32OrMinusZeroToBigInt if the input is typed as Integral32
in typed lowering.
- In simplified lowering, Integral32OrMinusZeroToBigInt is lowered
to conversion to word64 accordingly.
- If the input is not Integral32 or BigInt, JSToBigIntConvertNumber
is lowered to a builtin call in generic lowering.
Bug: v8:9407
Change-Id: I8539d742e82cce515bd9350797f5f9b0876ee6f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055670
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84761}
Similar to the `AsyncFunctionReject` builtin, the
`AsyncGeneratorReject` should also mark the promise rejection as a
non-debuggable event.
That is because the initial throw that causes the generator rejection
downstream alreay triggered the debuggable event.
We can re-use one of the existing tests as a regression test here:
If we wait for the Runtime.evaluate promise to resolve after the first
pause, we ensure that we already paused once. The test in its current
form swallowed the second pause implicitly by disabling the debugger.
R=bmeurer@chromium.org
Bug: chromium:1270780
Change-Id: I97ab08934804fefd097e9bd01081469da5379154
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084925
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84756}
On Mac, we spend around 30% of lazy compile time in {ThreadTicks::Now}.
On Linux it's less severe, but still around 10%.
That's too much overhead for measurements that only show up in UKM, so
remove that.
The unused fields will be removed from the UKM events after the plumbing
on the chromium side has been removed.
R=ahaas@chromium.org, mlippautz@chromium.org
CC=ecmziegler@chromium.org
Bug: v8:13565
Change-Id: I2dad88d899482801888940499d2d1761ff075578
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078966
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84754}
We introduce V8InspectorSession::stop API to enable safe
detach from the session. In particular, after calling 'stop',
the session will leave any instrumentation pause it might
be in and disarm all its instrumentation breakpoints.
This is useful when the session disconnect request is registered
on V8 interrupt (so it is unsafe to disconnect at that point),
and the execution should first get to the message loop
where the disconnect can be handled safely.
Bug: chromium:1354043
Change-Id: I3caab12a21b123229835e8374efadc1f4c9954c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4085143
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84753}
This reverts commit 331c577e1d.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20single%20generation%20-%20builder/9912/overview
Original change's description:
> [static-roots] Allow creating isolates from existing r/o snapshot
>
> This adds the ability to create an isolate from scratch, except the
> read only roots, which are initialized from a read_only_data snapshot.
> To do this we split the heap setup in a read/only part and the rest.
> The goal of these changes is to later support writing serializer tests,
> even if the read only roots are static and have to be loaded from a
> fixed snapshot.
>
> Bug: v8:13466
> Change-Id: I078695b95710e5281da013ca0c08af0e153b4725
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037271
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Olivier Flückiger <olivf@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84750}
Bug: v8:13466
Change-Id: I91512140abb98993578d27e65e6080e1d3f317e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4089967
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84751}
This adds the ability to create an isolate from scratch, except the
read only roots, which are initialized from a read_only_data snapshot.
To do this we split the heap setup in a read/only part and the rest.
The goal of these changes is to later support writing serializer tests,
even if the read only roots are static and have to be loaded from a
fixed snapshot.
Bug: v8:13466
Change-Id: I078695b95710e5281da013ca0c08af0e153b4725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037271
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84750}
This reverts commit 36bac1bcae.
Reason for revert: This possibly caused clusterfuzz issues and test flakiness.
Original change's description:
> [heap] Fix conservative stack scanning for client isolates
>
> With this CL, the context of stacks corresponding to all client isolates
> are saved, so that conservative stack scanning can be used correctly
> during a shared garbage collection. This happens:
>
> 1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
> isolate and the initiator;
> 2) when an isolate's main thread is waiting in a safepoint; and
> 3) when an isolate's main thread is parked.
>
> Bug: v8:13257
> Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84712}
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:13257
Change-Id: I7eb50b24243084d45b3f1bcc37a559b9f92e0318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092363
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84749}
This was a slightly overzealous optimization that ended up being more
tricky than expected without measurable value on the benchmarks (as far
as we know). Let's try to remove it and see whether an important
benchmark notices.
Bug: chromium:1385941
Change-Id: If2e81f6cb6758f9c373e7c2c8beaa308ed323f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4088624
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/main@{#84739}
Adds new `br_on_cast_fail <branch depth> <heap type>` instruction
with opcode 0xfb43.
The instruction branches if the cast fails. `null` is treated as a cast
failure (meaning the branch is taken).
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: I97a78d6d0872703ab825016cab4e737f8f79995f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084981
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84733}
Specifically, the methods in {WasmJSFunction} and {WasmCapiFunction}.
Drive-by:
- Fix a bug in {WasmCapiFunction::GetSignature}.
- Fix a bug in wasm-module-builder.js.
Bug: v8:7748
Change-Id: I7408d07766536ed37f23b97ad210212b986412bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079097
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84728}
Keep the ValueSerializer version number the same but add a separate
value type for resizable ArrayBuffers.
Bug: v8:11111
Change-Id: I895e9ffcc63cce2e83a09d4be81312fdcffa67f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4083067
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84718}
Adds v8::[Shared]ArrayBuffer::MaxByteLength and
v8::BackingStore::IsResizableByUserJavaScript.
This is needed for embedders who need to check if a buffer is resizable
by user JS, like blink, to check for the [AllowResizable] WebIDL
extended attribute.
Bug: v8:11111
Change-Id: Ie7e03979ef3884123df8a3eeb5c3516c4a6967c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4082276
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84715}
With this CL, the context of stacks corresponding to all client isolates
are saved, so that conservative stack scanning can be used correctly
during a shared garbage collection. This happens:
1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
isolate and the initiator;
2) when an isolate's main thread is waiting in a safepoint; and
3) when an isolate's main thread is parked.
Bug: v8:13257
Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84712}
Promoted pages are iterated to record slots containing old to new and
old to shared references. This takes a significant amount of time during
the atomic pause.
Instead we offload this task to the concurrent sweepers, record slots to
a local cache, and merge it when finalizing sweeping.
Array buffer sweeping depends on iteration of promoted pages, so it is
frozen until iteration is done.
See design doc at https://docs.google.com/document/d/1JzXZHguAnNAZUfS7kLeaPVXFfCYbf5bGCtyKgyiMDH4/edit?usp=sharing
Bug: v8:12612
Change-Id: Icdc79a7a70c53352e3a1b3961cfe369e8563b65b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062041
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@{#84706}
Adds new `br_on_cast null <branch depth> <heap type>` instruction
with opcode 0xfb4a.
The instruction branches on null.
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: I0f1debacc80a304f7cfc262fd2cde7f43fc804d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075086
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84703}
It turned out that executing 1 million (wasm) instructions can take way
over a minute on a simulator.
Thus changing this back to 16k instructions (as it was before
https://crrev.com/c/4078983). This takes around 5 seconds on my machine.
R=jkummerow@chromium.org
Bug: chromium:1396351, chromium:1396237
Change-Id: Ibf2ae2c81816be93807e564876b75aec18a57c42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079195
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84691}
The zone should just be a member of {WasmModule} instead of a
heap-allocated second object.
R=ahaas@chromium.org
Change-Id: I9cf7d5145ea9131a5ae3382c6f5aa63b816d9aa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080032
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84690}
This is a reland of commit eeed2ebadb
Changes since revert:
- Disable test for builds that don't support shared heap.
Original change's description:
> [heap] Invoke GC callbacks in safepoint for shared GCs
>
> After a shared GC, trigger all registered callbacks while the global
> safepoint is active.
>
> Bug: chromium:1395117
> Change-Id: I16c61533d44fbeddda18414d2256203848420a99
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079624
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84653}
Bug: chromium:1395117
Change-Id: I145dadac39d81342d7fbc2bad8b87f3518b0100e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4081130
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84687}
... so that we can check that we correctly installed a maglev
code during OSR.
Bug: v8:7700
Change-Id: I6f1d12e8b43cb7c0639e75c43400c5000c090a00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078937
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84686}
Shared heap is not available without write barriers, therefore skip all
tests that require shared heap when write barriers are disabled.
Change-Id: I66a9a94941ffab792ced964f12df6930b13c92cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079120
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84682}
This reverts part of crrev.com/c/4020425, because it turns out that the
runtime call pays off for strings above a certain length.
Bug: v8:12868
Change-Id: I1c4d5a01bb0f1303c2385c7707b3e5fff6936b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075728
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84668}
This reverts commit 7b138dd30d.
Reason for revert: Causes multiple flakes:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/22932/overviewhttps://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/41934/overview
Original change's description:
> [wasm] Compile debug code lazily
>
> 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
>
> Bug: v8:13541, chromium:1372621, v8:13224
> Change-Id: Ia36d9b8743523b1c89221c59f989268e27f6ce98
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067302
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84662}
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ic5442462d158618f2d43b8e0ebdfb90017ed378a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080034
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Owners-Override: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84665}
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
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ia36d9b8743523b1c89221c59f989268e27f6ce98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067302
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84662}
By applying the same special-case that the Torque builtin already has
to the runtime function.
This is a quick fix pending discussion what the right long-term solution
should be.
Bug: v8:13523
Change-Id: I5303d5ac598d00189f7eb2d9d78b81ad11b919b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075527
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84654}
After a shared GC, trigger all registered callbacks while the global
safepoint is active.
Bug: chromium:1395117
Change-Id: I16c61533d44fbeddda18414d2256203848420a99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079624
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84653}
This is a reland of commit bb288ea342
Changes since revert:
- Skip added test in single generation builds (shared heap is not supported in single generation).
- Use Isolate::Current() instead of GetIsolateFromWritableObject() for strings that reside in shared space (not only if the string is actually shared).
Original change's description:
> [strings] Don't try to record/update invalidated slots in shared space
>
> Strings in shared space are always direct (i.e. they don't contain
> pointers) and therefore cannot have any recorded slots.
>
> Drive-by: DCHECK no slots are recorded in shared space.
>
> Bug: chromium:1394741
> Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84630}
Bug: chromium:1394741
Change-Id: I6889b565f8a247ae1fe553158e29984e7c05563a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079224
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84652}
The OnProfileEndListener callback has to be reset before the isolate
dies to avoid a use-after-free when the Global which holds the callback
gets released.
Drive-by change: make the OnProfileEndListener callback
isolate-specific. At the moment a `profileEnd` call in IsolateA could
trigger the OnProfileEndListener callback of IsolateB, which could
cause all kinds of data races (the callback would access the isolate,
but the isolate is not supposed to get accessed by multiple threads
concurrently. With this CL there is one callback per isolate.
R=clemensb@chromium.org
Bug: chromium:1395237
Change-Id: Ifaa5b883a231f5519a3bfeb6187fb7d8faa02b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076465
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84646}
The fuzzers based on {WasmExecutionFuzzer} (wasm-code, wasm-compile)
were already switched over in https://crrev.com/c/4042288.
The wasm-async and wasm fuzzers were still testing against the
interpreter, even though WasmGC opcodes are enabled, which leads to
crashes due to incomplete interpreter support.
This CL now switches those remaining fuzzers to "liftoff as reference"
mode, and removes support for testing against the interpreter.
As Liftoff code runs a lot faster than the interpreter, we bump the
limit for the number of executed instructions from 16k to 1M.
R=jkummerow@chromium.org
Bug: chromium:1387316, chromium:1393379, v8:13496
Change-Id: Id3e6177cc89b49e69d03515f10eedaf0872bde82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078983
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84644}
For some reason, {OwnedVector} defines both a {start()} and a {begin()}
accessor which return the same value. As {begin()} is the name that the
standard library uses, this CL removes {start()} and switches all uses
to {begin()}.
R=mslekova@chromium.org
Change-Id: Ib505fe146db396f7589404c5a630e19248624729
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075865
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84643}
The wasm export wrapper passes the expected type as a Smi parameter to
the {WasmJSToWasmObject} runtime function. However, since this wrapper
might be compiled by a different module that is currently running it,
it is not enough to pass the module-specific type index and the module
to reconstruct the type. Rather, we must pass the canonical type
index.
Bug: v8:7748
Change-Id: I84e34e855898477a135f213f07bca10e95ecf49a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068123
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84641}
This refactors how we generate any decoding errors during streaming
compilation: Instead of generating an error message, we only remember
that decoding failed. After all bytes have been received, we then
synchronously re-validate the bytes. This ensures consistent error
messages between all decoding and compilation pipelines.
In order to achieve this, we now unconditionally store the full wire
bytes in the {StreamingDecoder}. This partially overlaps with the
section buffers that we already store, but we cannot continue filling
section buffers after a decoder error. This will be cleaned up in a
follow-up CL.
We can also remove most of the buffer-offset tracking, which will also
be done in a follow-up.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I1d506356de6a0070c3bf2b26470dbf781f4f62e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4066922
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84636}
This reverts commit bb288ea342.
Reason for revert: Failing on linux debug and TSAN run
- https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20single%20generation/7820/overview
- https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/22912/overview
Original change's description:
> [strings] Don't try to record/update invalidated slots in shared space
>
> Strings in shared space are always direct (i.e. they don't contain
> pointers) and therefore cannot have any recorded slots.
>
> Drive-by: DCHECK no slots are recorded in shared space.
>
> Bug: chromium:1394741
> Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84630}
Bug: chromium:1394741
Change-Id: I938dcac9cb5c9154ec9a3c5504b29f3208e3e369
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079145
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84632}
Strings in shared space are always direct (i.e. they don't contain
pointers) and therefore cannot have any recorded slots.
Drive-by: DCHECK no slots are recorded in shared space.
Bug: chromium:1394741
Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84630}
1) When transferring ArrayBuffers, retain resizability
2) Fix transmitting TypedArray flags; we cannot set the flags after
TypedArray creation, since the map would then be wrong.
Bug: v8:11111
Change-Id: Ic2fa3e6a4db1cb82a3751d2b114353fb477a54c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4064463
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84628}
As Wasm module can live longer than the isolate that initially created
them, it generally makes sense to use the WasmEngine's accounting
allocator for the decoded WasmModule.
Instead of passing that allocator through many functions, we can just
get it directly from the one global WasmEngine when we need it.
R=ahaas@chromium.org
Change-Id: I552f8e19072f2305a3186b821c2f5b3969eac83f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4071464
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84611}
Adds new `br_on_cast <branch depth> <heap type>` instruction
with opcode 0xfb42.
The instruction does not branch on null.
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: Id1d238645c176b32b568249d67fa28517b435ad4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4069559
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84598}
This CL fixed missing instance type checks for constant shift
amounts and corrected the use info for the lhs.
Bug: chromium:1393865, v8:9407
Change-Id: Id6e65f4e26a0436960b12196f29663429876398b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061075
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84596}
An {OwnedVector} that was moved or assigned to another {OwnedVector} was
left in an inconsistent state: {data_} was null, but {length_} was
non-zero.
This CL changes that to leave the moved-from vector in a valid (empty)
state, similar to what the {std::vector} move constructor and assignment
does.
R=mlippautz@chromium.org
Change-Id: I59b543b2cea4bc0e066b7817cee1de6b2b8a7735
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062089
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84594}
When importing a WasmExportedFunction into a module, we checked that
its type is equivalent with the declared type of the import. Instead,
we should check that the imported function has an isorecursive subtype
of the declared type.
Change-Id: I2a5f68d4c4c8c65a0eed5b82e8e825affb832cfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061732
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84593}
With v8_use_perfetto = true, tracing sessions are controlled by
Perfetto, not TraceLog. This can lead to inconsistencies, e.g.
TraceLog signalling trace start while V8's TrackEvent datasource
hasn't been initialized yet.
This CL removes the TraceStateObserver interface and replaces its
uses with perfetto::TrackEventSessionObserver which correctly tracks
Perfetto tracing sessions start and end.
See also crrev.com/c/4066184 for the corresponding Chrome change.
Bug: chromium:1006766
Change-Id: I94b2189c8b28aec8b17ec8fc1246e27c904e4ee9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062038
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/main@{#84590}
This is a reland of commit 8016f5c667
Additional HandleScopes are added in 3 spots and an additional
test was added to cover the crash that caused the revert.
Adding and removing the MicrotasksCompletedCallback should be
associated with the microtask queue of the Context. We store the
context as WeakPtr and always remove the callback when it completes
regardless of the state of the debugger.
BUG=v8:13450
Change-Id: Ie4d6edcb561c6753a6d34d84cfcf4989bb6e9321
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062397
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84584}
Array.of/from returned HOLEY elements kind even though their returned array can be PACKED, which made it hard to take fast paths for PACKED arrays.
This CL creates a PACKED array directly for the cases where the receiver is the default array function.
Bug: chromium:1305342
Change-Id: Id14124d029ea87dc7c9320f62087f63460acd446
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062669
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84582}
Array.reverse was optimized only for PACKED_* arrays. This CL adds fast paths for HOLEY_* arrays as well.
Bug: chromium:1305342
Change-Id: I83c5ffa6e823478992c2caabd9a88d405b35e464
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062673
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84580}
This was written in a single statement:
state_out->set(to_index, GetMoveSource(state_out, move));
which is unsafe, because it combines a Handle dereference, and a
potentially GC-triggering call (GetMoveSource).
By splitting the statement in two, the Handle is guaranteed to be
dereferenced after the potential GC.
R=dmercadier@chromium.org
Bug: v8:13544
Change-Id: I9645dabf602c16872356c225ad7f383ab7e457d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4066541
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84579}
If we'd do it before merging register values, we might drop a value from
a register that's needed by a phi.
Bug: v8:7700, chromium:1394036
Change-Id: I39be09d5ccf19ff70aaefc8865565f0d2169552c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4063692
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84576}
Disable incremental marking for the tests to make sure that the
generational barrier always fires.
Original change's description:
> unified-young-gen: Implement generational barrier for TracedHandles
>
> If unified young generation is enabled, we don't record all young nodes,
> but only ones that have old host. The same std::vector<TracedHandle*> is
> reused for the remembered set implementation.
>
> The barrier is added to TracedHandle creation, i.e.
> - v8::TracedReference::Reset(),
> - v8::TracedReference::operator=(const TracedReference&),
> and to moving between TracedHandles, i.e.
> - v8::TracedReference::operator=(TracedReference&&).
>
> Bug: v8:13475
> Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84513}
Bug: v8:13475
Change-Id: I329a0b52e1fb7a24abc130c6bc493ad1b1ccbfee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062040
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84553}
This CL adds one byte string specialization support for fast API call arguments.
It introduces a kOneByteString variant to CTypeInfo.
We see a ~6x improvement in Deno's TextEncoder#encode microbenchmark.
Rendered results: https://divy-v8-patches.deno.dev/
Bug: chromium:1052746
Change-Id: I47c3a9e101cd18ddc6ad58f627db3a34231b60f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4036884
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84552}
Make the setup_isolate_delegate stateless. It does not make sense to
pass a setup delegate to Isolate::Init that would contradict the
configuration of the isolate, hence it does not make sense to let the
delegate decide if heap objects should be created. Instead let the
isolate decide on how to invoke the delegate.
Cleanup in preparation for later changes to mksnapshot.
Bug: v8:13466
Change-Id: I5ca36a1db3e94baf068ba0dc91729a78086a023c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020172
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84550}
For performance profiling in DevTools, LogWasmCode has to be called on
every isolate for a NativeModule. After receiving a NativeModule from
postMessage, the call to LogWasmCode was missing.
R=clemensb@chromium.org
Bug: chromium:1381182
Change-Id: Ibbb5129a848477c42ac2a8fbc04b0e61ec8900eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051245
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84546}
We currently add two samples: One for the overall wire bytes size and
one for the number of declared functions. Both is not only available
during decoding, but also to the caller. Hence separate the update of
counters and events from actual decoding. This will make it simpler to
decode a module (for re-validation) without updating counters.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Ib00f4150cf2ad5452090f0aff8198b31d075b49d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061687
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84538}
This reverts commit e31a7192ee.
Reason for revert: TSAN failure for the newly added unittest: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/10056/overview
Original change's description:
> Reland "unified-young-gen: Implement generational barrier for TracedHandles"
>
> The dcheck was fixed in 7b40cb0c1b. The MSVC was also fixed.
>
> Original change's description:
> > unified-young-gen: Implement generational barrier for TracedHandles
> >
> > If unified young generation is enabled, we don't record all young nodes,
> > but only ones that have old host. The same std::vector<TracedHandle*> is
> > reused for the remembered set implementation.
> >
> > The barrier is added to TracedHandle creation, i.e.
> > - v8::TracedReference::Reset(),
> > - v8::TracedReference::operator=(const TracedReference&),
> > and to moving between TracedHandles, i.e.
> > - v8::TracedReference::operator=(TracedReference&&).
> >
> > Bug: v8:13475
> > Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#84513}
>
> Bug: v8:13475
> Change-Id: I8ecde011af077a818b7b96af57e15b607febb185
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061693
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84533}
Bug: v8:13475
Change-Id: I05a179a5ef79890640bba450c4f3e3178c38228f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061464
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84536}
The dcheck was fixed in 7b40cb0c1b. The MSVC was also fixed.
Original change's description:
> unified-young-gen: Implement generational barrier for TracedHandles
>
> If unified young generation is enabled, we don't record all young nodes,
> but only ones that have old host. The same std::vector<TracedHandle*> is
> reused for the remembered set implementation.
>
> The barrier is added to TracedHandle creation, i.e.
> - v8::TracedReference::Reset(),
> - v8::TracedReference::operator=(const TracedReference&),
> and to moving between TracedHandles, i.e.
> - v8::TracedReference::operator=(TracedReference&&).
>
> Bug: v8:13475
> Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84513}
Bug: v8:13475
Change-Id: I8ecde011af077a818b7b96af57e15b607febb185
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061693
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84533}
Fuzz parallel moves that may modify the stack layout in
cctest/test-code-generator. This requires some changes in the test
environment to keep track of the the input and output layouts.
R=dmercadier@chromium.org
Bug: chromium:1269989
Change-Id: I872bf5d79b8275595f21fa9236e4634331078053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4047488
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84530}
When TurboFan generates code for TypedArray access for which we have
seen different ElementsKinds, we might end up accessing the TypedArray's
length directly when we are inlining into a call site where the
TypedArray is known. This access could also happen for ElementsKind
cases that are different from the actual TypedArray, which caused a
DCHECK failure for cases where length access is prohibited (e.g. for
rab/gsab backed TAs).
Since these cases are not reachable at runtime, this CL removes the
incorrect length access and generates an Unreachable node in the graph
instead.
Bug: chromium:1393942
Change-Id: I1171531210bf6d1f14a58c4beefb0a3b70a646cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061314
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84524}
1) Parameter conversions resizing the underlying buffer but *not* in a way that would make a length-tracking TA go OOB.
2) Special case of the former: resize to 0.
Bug: v8:11111, chromium:1392577, chromium:1393375
Change-Id: Ia0f54fc4530618fa2313737d6c643abdb24b9a36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055630
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84519}
This reverts commit d164f933b8.
Reason for revert: Failure on YoungUnifiedHeapTest: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20no%20pointer%20compression%20debug/1954/overview (Mac arm64)
Failure on Linux: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/51267/overview
Original change's description:
> unified-young-gen: Implement generational barrier for TracedHandles
>
> If unified young generation is enabled, we don't record all young nodes,
> but only ones that have old host. The same std::vector<TracedHandle*> is
> reused for the remembered set implementation.
>
> The barrier is added to TracedHandle creation, i.e.
> - v8::TracedReference::Reset(),
> - v8::TracedReference::operator=(const TracedReference&),
> and to moving between TracedHandles, i.e.
> - v8::TracedReference::operator=(TracedReference&&).
>
> Bug: v8:13475
> Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84513}
Bug: v8:13475
Change-Id: I0d97f8cdd0b2e95c7a21b78dacd25c38d08f5a16
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062087
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84516}
If unified young generation is enabled, we don't record all young nodes,
but only ones that have old host. The same std::vector<TracedHandle*> is
reused for the remembered set implementation.
The barrier is added to TracedHandle creation, i.e.
- v8::TracedReference::Reset(),
- v8::TracedReference::operator=(const TracedReference&),
and to moving between TracedHandles, i.e.
- v8::TracedReference::operator=(TracedReference&&).
Bug: v8:13475
Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84513}
Currently V8 recompiles all functions of a WebAssembly module with
TurboFan when a debugging session ends. This is outdated behavior and
causes OOMs for developers. With this CL all debugging code gets removed
when a debugging session ends, and functions get re-compiled lazily.
This behavior may lead to slightly worse performance for some time after
debugging finishes, but it avoids OOMs, and developers are used to
debugging code being not as performant as production code.
R=clemensb@chromium.org
Bug: chromium:1372621, v8:13224
Change-Id: I9fc97408ef92ad5564f2a9743213762226c2b25e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055923
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84509}
PPC has a smaller wasm code space compared to other platforms and
as a result can't execute modules with large number of functions.
More details are available under the comment section of
crrev.com/c/4027963
Change-Id: I0531ec855ee9ffa5542bf0527287a3e49e1cdb0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4053377
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#84491}
This test had to be updated for --shared-space because the main isolate
is always parked when the client isolate requests a GC. In such cases
the GC isn't performed and therefore the weak handle not reset.
The CL moves the client isolate into a proper thread which allows the
main isolate to remain in the running state.
In addition this CL adds the BasicMemoryChunk::ComputeMarkBit
methods. These methods make it easy during debugging to compute
the MarkBit (cell + mask) for an object.
Bug: v8:13267
Change-Id: I6680d8d1d8b36d86b22c43399abbd4325f64ccb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4054622
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84488}
If a value is used after a try-block finishes, we need to make sure that
the catch-block can restore its value. Otherwise we'd accidentally drop
the value on register merge thinking we're in a liveness hole on the
merge after the catch (since the catch cleared all the registers). This
then breaks JumpLoops that need to restore the value in a specific
register.
Bug: v8:7700, chromium:1392061
Change-Id: I7255ccf9b36bf36583ad612882137b251c48caed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055111
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84483}
HeapTest.GrowAndShrinkNewSpace emulates a GC cycle for shrinking new
space. Starting a new MinorMC cycle should first finalize sweeping from
the previous GC cycle.
Bug: v8:12612
Change-Id: Iea35b54ba0f7be3b7870c557c92042a8d9896045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055625
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@{#84475}
The WasmModuleBuilder is used in tests for creating Wasm modules. It can
be pretty slow for huge modules, in particular in simulator builds or in
slow variants like gc-stress.
This CL adds a fast path to the code section creation, for functions
without locals. This makes the wasm-max-functions test 1.45x faster in
the arm64 simulator (generation of the code section alone gets 2.2x
faster).
R=ahaas@chromium.org
Change-Id: I993542448fb4f0b5fdadca13c59691d86844e2a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051606
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84465}
This reverts commit a63f9912b7.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/50370/overview
Original change's description:
> [maglev] Spill nodes that we'd otherwise fail to merge
>
> This makes sure that catch-blocks don't accidentally drop values that
> are only in registers, which can happen if we throw in deferred throwing
> code (e.g., in ThrowReferenceErrorIfHole). At the latest we'll discover
> such values when trying to merge after the catch block, noticing we
> can't find the value through the catch-block. Unfortunately it's not
> trivial to figure out where that merge happens, so we just
> unconditionally spill the value.
>
> For liveness holes (as the comment previously mentioned) the value
> should already be dead and dropped on the merge. Running --maglev-stress
> etc shows that no code currently hits this path, except for the added
> test that shows the issue with catch blocks.
>
> Bug: chromium:1392061
> Change-Id: Ied0b1d4b430c9af2e7ae3dfc004ecb45037c5735
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051605
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84448}
Bug: chromium:1392061
Change-Id: Iddbd7b19bc73e352dbd6867db990238f80adbdda
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055504
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84455}
Function#call needs a function to call, so don't try to lower it to a
builtin call when there's no function.
Bug: v8:7700
Change-Id: I6705e2900731b2be2830231f8ab0dbfcdca5f594
Fixed: chromium:1392936
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055680
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84451}
This makes sure that catch-blocks don't accidentally drop values that
are only in registers, which can happen if we throw in deferred throwing
code (e.g., in ThrowReferenceErrorIfHole). At the latest we'll discover
such values when trying to merge after the catch block, noticing we
can't find the value through the catch-block. Unfortunately it's not
trivial to figure out where that merge happens, so we just
unconditionally spill the value.
For liveness holes (as the comment previously mentioned) the value
should already be dead and dropped on the merge. Running --maglev-stress
etc shows that no code currently hits this path, except for the added
test that shows the issue with catch blocks.
Bug: chromium:1392061
Change-Id: Ied0b1d4b430c9af2e7ae3dfc004ecb45037c5735
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051605
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84448}
A shared GC needs to reset weak global handles that store pointers
to shared objects which die during the shared GC.
Bug: v8:13267
Change-Id: I3800bf1173f42dd9ab96be4add462547b2a8f4a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051602
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84444}
The test is slow and timeouts easily.
R=manoskouk@chromium.org
Bug: chromium:1380561
Change-Id: I413891a73daa1f2ef9d9537b35b8543495a0ccac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4048122
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84430}
This is a reland of commit 7bf94d0336
Changes since revert:
- Update string forwarding table with evacuated objects in mark compact.
- Always mark forward objects in string forwarding table.
Original change's description:
> [heap] Transition/Shortcut strings only during GCs without stack
>
> By limiting transitions of (shared) strings and shortcutting of
> Thin/Cons strings to GC withouts stacks, optimizing compilers can rely on
> the invariant that string maps do not change during a GC, allowing them
> to eliminate map checks and enable more aggressive optimizations.
>
> Change-Id: Ic9c9ed7b04b2ceed369484bf048965c083a9a693
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030578
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84347}
Change-Id: I1ab0965ff421635457a66fbe7f178d951afe4402
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035240
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84424}
This fixes a bug where the {types} vector automatically reserved
additional space, and by comparing with its capacity we failed to
register an out-of-bounds error.
Using capacity over size has led to bugs before, and using it correctly
(reserving as much space as needed manually) prevents vectors from
reserving space exponentially. Therefore we are switching to using size
for bounds checks instead.
Bug: v8:7748, chromium:1388942
Change-Id: I3cb8de4f113aaa6d70e45557161fd4c268861f1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4046221
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84419}
There exists a limit in the WebAssembly specification on the maximum
number of functions allowed in a module. For release builds the limit
seems high enough for now, but we got developer feedback that their
debug builds exceed this limit. To support these developers without
violating the specification this CL introduces a V8 flag that allows
to specify a custom limit. Developers can then increase this limit
locally for their debugging sessions.
R=clemensb@chromium.org
Bug: chromium:1380561
Change-Id: Ie65a47d49e9ca1d8b05617df0f46c187afef06e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027963
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84417}
Global/traced handles are only ever used with two callbacks:
* MarkCompactCollector::IsUnmarkedHeapObject
* IsUnscavengedHeapObjectSlot
IsUnscavengedHeapObjectSlot already works with shared heap objects
because it only applies to objects in the young generation.
This CL fixes MarkCompactCollector::IsUnmarkedHeapObject with shared
heap objects. E.g. a local GC isn't allowed to load markbits for
shared objects.
Bug: v8:13267
Change-Id: Id0fb9ed73409e384eed4c7168100a1bf40a06f94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4044362
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84414}
... instead of computing them on the fly. This approach seems to
perform slightly better because it requires less code.
Bug: v8:7703, v8:11460
Change-Id: If31a06fbc748251c491c011e9e3f118665e20159
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020456
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84413}
With shared space (instead of the shared isolate), the AccessorInfo
implementation of SharedArray's length property is no longer threadsafe.
Until AccessorInfos can be put into shared or RO space, go back to
storing the length field as a per-instance in-object field, which is
unfrotunately a little wasteful.
Bug: v8:12547
Change-Id: I99c1cbf26047da48a4b4c11e14ab7def7d4e4f60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4039309
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84408}
Clear OLD_TO_SHARED slots in free memory after shrinking large objects.
This CL now clear all slots outside of the object and not just from
the next OS page boundary.
Since we are already here also stop clearing OLD_TO_NEW and OLD_TO_OLD
since they should already be cleared at this stage of the GC. Add
DCHECKs that this always holds. We also don't need to iterate large
code objects since we do not shrink such pages anyway.
Bug: v8:13267, chromium:1385717
Change-Id: I75f6e56a7c13974ce669bbba29262e95eb94d287
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037981
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84407}
Currently, if a script is compiled on the main thread or deserialized on
any thread, and a matching Script object is found in the Isolate
compilation cache, the new content is merged into the existing Script.
This CL implements the same merging for scripts which were compiled by a
background task. I expect speed changes to be minimal, because merging
is only needed in a small minority of compilations. When needed, it
usually takes about 10% as long as the deserialization of the script,
which in turn is faster than compilation from source text.
This CL also removes some code which I added in preparation for merging
on a background thread in this case. Upon further discussion, we've
determined that the extra round trip to a background thread when the
main thread is likely just waiting for completion would do more harm
than good, and performing the compilation cache lookup from the
background thread would be quite cumbersome.
Bug: v8:12808
Change-Id: Ia7a14a739779ab658b505572d19df4ec489a078e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023904
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84402}
The gap resolver issue that this was blocked on is fixed now.
R=clemensb@chromium.org
Bug: chromium:1269989
Change-Id: I1aa4566190dd9705bf5688f5c551923f6273f93e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042243
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84398}
This CL implements Torque builtins for BigInt left shift and right
shift and truncates shift operations when the shift amount is a
constant.
- Propagate truncation if we know the operation is a left shift.
- Lower the operation to a word64 right shift if the lhs is Signed- or
UnsignedBigInt64 and we know the op is a right shift.
A side effect of truncating left shift is it will not throw a
BigIntTooBig exception in optimized code.
Bug: v8:9407
Change-Id: Ibd42cf897ef8a35f6addd09674faf409654d6d7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028142
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84396}
Otherwise we may pass an out-of-bounds type to {IsSubtypeOf}.
Bug: v8:7748, chromium:1388938
Change-Id: Ifcbf31c68da40d7b7a365c9d756cd5fa81347291
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4040930
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84395}
The interpreter does not implement WasmGC, hence always use Liftoff as
reference if WasmGC opcodes are enabled.
R=manoskouk@chromium.org
Bug: v8:13496, chromium:1387316
Change-Id: I29f496ebc1921c727c216dda763c1e9a63d6597b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042288
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84392}
The test fails with multiple isolates because with the NativeModule
cache the second isolate can create an unexpected state for the first
isolate.
R=clemensb@chromium.org
Bug: v8:13503
Change-Id: Ic83d374c61703fdeb570b65b3c444ab0ae3cef8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4040929
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84391}
This adds an implementation for the {kRef} case in
{MakeDefaultArguments}.
R=jkummerow@chromium.org
Bug: v8:13496, chromium:1391168
Change-Id: I4c0e85b46c50f766816f799e80cf1afbe6fa258a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042663
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84386}
1) Pass {WasmFeatures} by value, it's a single word.
2) Pass a {base::Vector} instead of {start} and {end} pair.
3) Remove a redundant constructor (just pass an empty wire bytes vector
instead).
R=thibaudm@chromium.org
Change-Id: I337c3c86960505ae23c88cb6adc5646a61111f76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030434
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84382}
This adds a regression test for https://crrev.com/c/4025548.
Using {addBodyWithEnd(body)} makes the test a lot faster, and we just
skip it on known-to-be-slow variants.
In a default release build, the test takes ~0.3 seconds. In an x64 debug
build, it takes 17 seconds.
Bug: v8:13436
Change-Id: I63e2927774601b24d177b03cf075f9a8d287e934
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4031206
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84371}
Tail calls generate parallel moves that don't preserve the stack
layout, which is not always correctly handled by the current
gap resolver algorithm. Introduce a more robust algorithm that
handles any parallel move.
Design doc:
https://docs.google.com/document/d/1WbX5B4ej9MzsJ28JS4J5cF2eiJhKyX39vAUB7GSA5YE/edit?usp=sharing
Also remove the move-splitting logic. The problem that it addresses
(swapping aliasing FP registers of different widths on arm) is already
handled by the new algorithm.
Bug: chromium:1269989
Change-Id: I575d5b56e0d949e3226388e06052292680b66044
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030580
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84366}
The CL implements an old-V8-to-young-Oilpan remembered set together with
a generational barrier.
Bug: v8:13475
Change-Id: I5f09f7c6db397f2a49cb0c47fd758a1604af4e83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030433
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84365}
The End block is not necessarily the last one in the RPO. Iterate
until the end but skip the end block.
Bug: chromium:1381131
Change-Id: I5e1cd19c1b3bea4cbe565319631a7686ed2352fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4017313
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84364}
