TurboAssembler::Switch considers its "condition" input is 64-bit.
However, Maglev's inner integers are rather Smis/32-bit integers.
Because we didn't not sign-extend the condition before calling
TurboAssembler::Switch, negative values were treated as positive
rather than negative.
Fixed: chromium:1403749
Bug: v8:7700
Change-Id: I78e934045330012186dc83dea0dc620ec977380a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128080
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85049}
`CpuProfiler::StopProfiling()` return `nullptr` if no profiling is
active. Thus a `nullptr` check is needed before serializing the profile
returned by `CpuProfiler::StopProfiling()`.
R=clemensb@chromium.org
Bug: chromium:1394663
Change-Id: I364eeb1d9bd670de5179e242c4462f0fbfc9c607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4126234
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85047}
.. which should result in 0 if x is non-negative, and -0.0 otherwise.
- Fix two invalid modulus-related folds.
- Handle aliased inputs in Int32ModulusWithOverflow.
- Drive-by: rename left/right to lhs/rhs to match the algorithm
description.
Note there is no deopt loop here since a result of -0.0 will update
feedback to kSignedSmallInputs.
Bug: v8:7700
Change-Id: I84fca0e43ded152d3520cbe73cc43299ff1c4230
Fixed: chromium:1403575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128081
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85039}
The Sub macro sometimes needs a scratch register when the 2nd operand
is too large to be encoded in the instruction. The prologue was
already reserving 2 scratch registers, which made Sub crash on a
DCHECK when trying to reserve one more scratch register.
Bug: v8:7700
Change-Id: I995689b8b16e3ef216641f0b6cadbf58f7f3740b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128554
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85029}
Mark rhs as clobbered since we may negate it. Negate the lhs in rax.
Bug: v8:7700, chromium:1403470
Change-Id: I9a26de78fcd8d1db90c1d26617001c0c699c350e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110814
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85021}
As a drive-by this also fixes property load from smi. We still need to check that we actually have a smi...
Bug: v8:7700, chromium:1403280, chromium:1403323
Change-Id: I3c4f050b94550b8d7e4e65f733f9c1dad47941d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120575
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85015}
Even if we have a constant load, if the map is not stable, we cannot
guarantee that the load is preserved across side-effecting calls.
Fixed: chromium:1403324
Bug: v8:7700
Change-Id: Ib900cf7574711115439e6521ed8cfaa866525e78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4123532
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85014}
It's possible that various branches merged already with a value that's
in a liveness hole, but we only figure out later. If so, drop the merge
as well.
Bug: v8:7700, chromium:1403399
Change-Id: Ifd97e0c1959ffe51017e400fb028041047885a9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111932
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85013}
The issue causing this test to fail on the usban bot was fixed with
https://crrev.com/fcda478d890caea6bf04a50e6106682b64cf8d5a
Bug: v8:13611, v8:13612
Change-Id: I1d0a713160cdddf8623e767d43277a988509bce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110955
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85007}
This CL plugs the hole in the outside<-ShadowRealm direction (i.e.
getting a reference to an object inside of the ShadowRealm from outside
the ShadowRealm).
This is a follow-on CL to
https://chromium-review.googlesource.com/c/v8/v8/+/4108810, which
plugged the getFunction hole in the ShadowRealm<-outside direction (i.e.
getting a reference to an object outside of the ShadowRealm from inside
the ShadowRealm).
Bug: v8:1198
Change-Id: Ic06533ba8b1cc6477ef9d55a23cb8b0b6584d4a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4115657
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85003}
With smi feedback, we use int32 operations for arithmetics.
When negating 0, we have to fallback to float as we can't represent -0
in int32. We can simply deopt in that case without causing a deopt loop, as a non-smi result will change the feedback to kSignedSmallInputs (from kSignedSmall).
Bug: chromium:1403102
Change-Id: Ic27c267349a1de6904639e91b1cade2c4f7d1fe2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4122829
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84998}
This CL introduced four more operators in TurboFan: BigIntLessThan,
BigIntLessThanOrEqual, and the corresponding speculative operators so
that all the BigInt comparisons are supported.
This CL also implemented fast paths for small BigInt inputs.
Bug: v8:9407
Change-Id: Iaa2d4dbebf68656d775a7feb65b97fb5c598ec23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111951
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84995}
After https://crrev.com/c/3859787 those frames would be printed like
standard Wasm frames, but in the place of the WasmInstanceObject, they
have a WasmApiFunctionRef object instead.
So special-case the {WasmToJsFrame::instance()} to load the instance
properly. Also special-case the {position()} accessor for imported
functions.
R=victorgomes@chromium.org
Bug: chromium:1402270
Change-Id: I39805805a50e7a73d7d8075c63c46bdf5a373a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4116778
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84993}
It's failing regularly on the ubsan bot, closing the tree.
This CL also adds a 'variant == future' section in the mjsunit.status
file to enable easy disabling of maglev-specific failures.
No-Tree-Checks: true
Bug: v8:13612
Change-Id: I3c0f7725e1fb36577e97c662cd3830c64ba298e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120554
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84982}
The spec does not allow side effects on wrapping the exceptions
crossing the realm boundaries. We need to provide an easy way to inspect the exception-thrown cross-realms according to the last TC39 meeting
consensus.
Related spec change: https://github.com/tc39/proposal-shadowrealm/pull/382.
Bug: v8:11989
Change-Id: Ia78d94fd33cba689267aeacd028d662bd4a37fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3618759
Commit-Queue: Chengzhong Wu (legendecas) <legendecas@gmail.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84961}
With this change property accesses on WasmObject and WasmArray return
undefined instead of throwing.
Furthermore retrieving the prototype of a WasmObject/WasmArray returns
null.
Bug: v8:13523
Change-Id: I12e3b9fb6ac9a7305f001a3b3835854068c3064f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110995
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84957}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
