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}
Most verification calls are gated behined both a build flag and a
runtime flag. Some calls were missing the runtime flag.
Bug: v8:12612
Change-Id: I482bf7cd3900e860f9db1932f9490d1af9b19df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4085007
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84932}
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}
Maglev OSR uses the deopt_reason to tell the deoptimizer not to
invalidate optimized code on deopt (since we deopted not because of a
failed assumption, but just as part of the OSR procedure). This deopt
reason must always be emitted for the code to work as expected.
Bug: v8:7700
Change-Id: I96b09eef52b2b90c6c491ffec3f87538124cdc88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111165
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@{#84930}
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}
... and other nodes needed for testing it.
Bug: v8:7700
Change-Id: I2e71916112bf9ac5ab336adb819aad4c4c5c6f8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111161
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84927}
Small optimization: We can save about 10% of the calls to
`FastZoneVector::Grow` during validation of large modules (e.g.,
psweb_2021_09.wasm: before 237k, after 215k calls to Grow) by
pre-allocating the `stack_` and `control_` vectors (which are unlikely
to remain empty for most functions). The runtime doesn't improve much
though (before 69.08ms validation time, after 68.45ms), but I guess it
is still worth the fewer re-allocations+copies.
I tried different amounts of pre-allocation as well (8, 16, 32, 64
elements). For both value and control stack 16 was the sweet spot: It
reduced more re-allocations than 8, but after 16 the number of Grow
calls plateaus and instead runtime increases slightly.
Change-Id: Idc57e0a31c6fa1bbdc98bfd4ffd5522d34f09e81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4107389
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84926}
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}
immediate_crash.h still uses V8_CC_GCC define to determine which
IMMEDIATE_CRASH macro is used. This should be V8_CC_GNU instead.
Otherwise weird compile errors are happening with turboshaft.
Bug: chromium:819294
Change-Id: Id77fe7406ae16a804e1e466844f81d6c728ec008
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111849
Commit-Queue: Stephan Hartmann <stha09@googlemail.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84923}
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 fixes a segfault encountered when disassembling a particular
flavor of invalid module using wami's --full-hexdump mode.
Change-Id: I5fbb97c2359d14ce9d4b6830b55a75cc34e964a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3919231
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84912}
Optimize the multimap iteration in ConstPool::PatchEntries to not use
equal_range/upper_bound to iterate over sub-ranges, but instead iterate
over the multimap directly, switching between sub-ranges as we detect
changes in the key.
Change-Id: I861123542f940c4d05e1a7877f41a92373f859a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110829
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84911}
This changes a few implementation details in the {Assembler} class on
x64, to make clang generate better code for it. This might also result
in slightly faster performance when generating code, especially in
baseline tiers.
R=jkummerow@chromium.org
Bug: v8:13565
Change-Id: I47e1bc559a5589e0f618ef1ced94966cf6538df5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110922
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84910}
This CL adds a more thorough way of trying to allocate code range
closer to .text section. It can be enabled by
--better-code-range-allocation flag which is off by default.
Add --trace-code-range-allocation flag to trace the code range
allocation process.
Add --abort-on-far-code-range flag to issue a fatal error if the code
range ended up allocated too far away from .text section.
Bug: v8:11880, chromium:1400973
Change-Id: Ie16f9bf64b48a815be771e3c02e2c1c6dcdb20eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110760
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84909}
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}
We see failures in the wild when finishing streaming wasm compilation.
This CL adds CHECKs that we do not accidentally finish or abort a job
multiple times, since many methods actually delete the
{AsyncCompileJob}, so calling such methods twice would lead to a
use-after-free.
R=jkummerow@chromium.org
Bug: chromium:1399790, chromium:1400066
Change-Id: I0b83b1e402444afd4444638d5c9a2fd31a78b056
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110762
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84905}
This reverts commit e63bae121b.
Reason for revert: Speculatively reverting since NCI is disabled and _WithFeedback builtins are hot in speedometer.
Original change's description:
> [compiler] Enable feedback collection in generic lowering
>
> Turbofan now has support for generating generic code in two variants,
> with and without feedback collection. Currently, feedback is collected
> only for some load and store operators (historical reasons).
>
> This CL enables feedback collection for (almost) all operators by
> default. The exception in the default TF configuration are call and
> construct variants (see also https://crrev.com/c/2276042). In NCI mode,
> all operators collect feedback.
>
> Regression have looked acceptable in our benchmarks so far. This is an
> experiment to see impact on real world. If successful, the
> non-collecting variants can be removed.
>
> Bug: v8:8888
> Change-Id: I0dddc7113ce94071552d5c4d992471db5ac5f989
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239571
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68710}
Bug: v8:8888
Change-Id: I5622528383c6194ccda639041291900144465782
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110858
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84904}
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}
Fix a non-terminating recursive call in BitwiseAnd/Or/Xor to instead
perform the truncation + bitwise op directly.
Also, fix up Generate_BitwiseBinaryOpWithOptionalFeedback to allow
passing in optional feedback. This is a drive-by from attempting to fix
the above issue by calling Generate_BitwiseBinaryOp.
Bug: v8:9407
Change-Id: I2f91779de5533d1911b408f80664a4c9ae5c7342
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111545
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84900}
EmbedderRootsHandler is still supported.
Bug: v8:13207
Change-Id: I91107a2ed8c9603b77ae3e487f396c9ba32f3f95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111523
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84899}
... where scratch scope is no longer active and the registers
could be clobbered.
Bug: v8:7700
Change-Id: I366312e2cafd732199b4668fd5f40363688c8a04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4107089
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84897}
This CL handles the conversion from Float64 (MinusZero) to Word64 in
the representation changer.
In the original CL, the range of Numbers eligible for optimization was
incorrectly set to Integral32OrMinusZero. This CL narrows it down to
Signed32OrMinusZero or Unsigned32OrMinusZero (but not the union).
Bug: v8:9407, chromium:1400897
Change-Id: I0f09eb512e77b145b081ad5d52ca03f61d49dc62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110761
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84896}
Oilpan young generation currently remembers all weak callbacks to be
processed on each GC. This is needed to support UntracedMembers in the
old space. If the old object with UntracedMember (e.g.
ActiveScriptWrappableManager) holds a pointer to a young object, the
custom weak callback must be reexecuted on each minor GC, because the
custom callback is responsible for clearing UntracedMembers.
This is not necessary for weak containers. They hold WeakMembers, for
which we issue the regular write barrier. The CL distinguishes between
callbacks for weak containers and for custom objects. This aims to
speeds up weak processing, which currently may take >10ms.
Bug: v8:13475
Change-Id: I6964a6835dc84febddbefb5e2952d57f108d1232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080470
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84895}
This CL implements a new %CheckTurboshaftTypeOf(e, type_string)
intrinsic allowing tests to express that the expression e is supposed
to have the turboshaft type expressed by type_string eventually during
lowering.
Test that use this intrinsic are verifying implementation details and
are thus somewhat brittle and potentially platform depedent. This
intrinsic is not supposed to be used broadly, but rather to write
some tests that check the precision of turboshaft's new type system.
This intrinsic may be removed once the type system is shipped and gets
coverage in other ways.
Bug: v8:12783
Change-Id: I4cc2582273f3d668601a3203c400a8461b470cac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061889
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84894}
... and any other node needed to test it.
Bug: v8:7700
Change-Id: Ia37fdcb1db3b6fb986f026696454d443236d011c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111600
Reviewed-by: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84893}
For asm.js functions, the script name is used as the `source_url` for
code logging. If the script name was undefined, as it can happen for
asm.js code that gets evaluated in an eval, then `nullptr` was used
as the `source_url`. The problem was, the logging code accessed
`source_url` unconditionally, which caused a segfault.
With this CL the empty string is used as `source_url` instead of
`nullptr`.
The test revealed another problem in the isolate mode: profiling has
to be stopped and the profiler disposed before the isolate dies.
R=clemensb@chromium.org
Bug: chromium:1395401
Change-Id: Ia9730bb033a22b799ea2b1903ea540db9f259513
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079685
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84892}
Rolling v8/build: 3d4b0c1..c72e275
Rolling v8/buildtools: 202b660..80c045e
Rolling v8/buildtools/linux64: git_revision:70d6c60823c0233a0f35eccc25b2b640d2980bdc..git_revision:5e19d2fb166fbd4f6f32147fbb2f497091a54ad8
Rolling v8/buildtools/third_party/libc++/trunk: 5239965..2948540
Rolling v8/buildtools/third_party/libc++abi/trunk: 25a3d07..123239c
Rolling v8/buildtools/third_party/libunwind/trunk: 09a1f53..5e22a7f
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2f1cf61..c6c2247
Rolling v8/third_party/depot_tools: a964ca1..5decb17
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20221209.0.1..version:11.20221213.1.1
Rolling v8/tools/clang: 3344dd8..7356f69
Change-Id: I2c8919fd71e138733ec8b793f36cea37b8c984e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111704
Commit-Queue: Liviu Rau <liviurau@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84891}
My recent change https://crrev.com/c/4071249 caused some slowdowns when
using Maglev. This change is an attempt to improve the speed of encoding
translation arrays by:
1. not converting signed values to unsigned (base::VLQConvertToUnsigned)
until after we've finished comparing the value to the previous value
and determined we need to write the value into the result array,
2. comparing only used operands, not all five possible operands (some of
which were guaranteed to be zero), and
3. calling ZoneVector::push_back directly rather than using
base::VLQEncodeUnsigned for cases where a value is known to be
representable in a single byte (opcodes and register numbers).
I don't have great faith in my benchmarking results, but this seems to
decrease time in V8.TFCodeGeneration by 3-5 ms on Octane.
Bug: chromium:1396229
Change-Id: I0e5714ef5e499ec64369414fb336fa1462d99164
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4086125
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84887}
This reverts commit fffae64444.
Reason for revert: Causes failures since an isolate in state
TEAR_DOWN might still park itself.
Original change's description:
> [heap] Ignore client isolates that are tearing down
>
> Client isolates that tear down only participate in the safepointing
> protocol to remove themselves from the list of all clients without
> blacking global safepoints.
>
> However, we do not need to consider them for the root set since such
> isolates will just detach as soon as possible and therefore are not
> allowed to touch the shared heap anymore anyways.
>
> This fixes a heap verification bug where heap verification fails for
> an isolate that tears down fails because the external string table
> was already finalized.
>
> We also can't move external string table finalization after detaching
> since then we would have races on the shared external pointer table.
>
> Bug: v8:13267, chromium:1401078
> Change-Id: I7d97c2d223bd87f620d9a92a9266be7b88afd9c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110857
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84870}
Bug: v8:13267, chromium:1401078
Change-Id: I0c9fb1adad850b834a79cb64e535051c30762397
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112005
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84886}
