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}
The location I added this in is wrong as it inherits the flag state
from VERIFY_PREDICTABLE, which I did not intend. This patch moves
the location earlier so that it doesn't pick up state from other
flags.
Bug=v8:13477
Change-Id: I23df7e778690e8b9f588cd2ce3db318c5fa22cb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112146
Auto-Submit: Scott Violet <sky@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84885}
This stores the CallDescriptors used for i64 <-> BigInt conversion
builtins as process-globals on the WasmEngine, instead of creating
them as temporaries whenever they're needed.
The primary purpose of this change is to simplify the interface to
the Int64Lowering by eliminating its "special case" parameter, in
preparation for moving that lowering to a different point in the
compilation pipeline.
A minor secondary benefit is that this will save a little bit of
(repeated) Zone memory usage.
Bonus change: drop the Int64Lowering from 64-bit builds, where it
isn't used, but was compiled in up to now. This saves ~17 KiB on
Android-arm64 builds.
Change-Id: Ib35d2e0f772110652eb05abd4c42d848108164b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110898
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84884}
Simply using the AlwaysAllocateScope on threads other than the
isolate's main thread may violate DCHECKs that this scope isn't
enabled.
However, we were using this mechanism to make GC allocations less
likely to fail. This CL therefore switches to another approach where
we simply allow allocations from the GC.
Bug: v8:13267, chromium:1401180
Change-Id: I3c6a34440af3ed87a8b50707006153416b3dbf42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111642
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84882}
With lazy compilation (and without lazy validation) we will have
validated all functions when starting Liftoff compilation. Thus
validationg again during Liftoff compilation is unnecessary overhead.
This CL removes validation from Liftoff compilation, saving both binary
size of V8 and performance in the default configuration. In the unlikely
case that we did not validate before (e.g. because we run eager
compilation or lazy validation is enabled), we explicitly validate the
function body before starting Liftoff compilation.
R=ahaas@chromium.org
Bug: v8:13565
Change-Id: I08bcac755081333795d78625bf1fc8cae856f255
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092496
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84881}
HandleSlot was only checking whether the target object is in the
shared heap but that flag is only set after the GC for large pages.
This CL fixes this by also checking for SHARED_HEAP_PROMOTION.
Bug: v8:13267, chromium:1401069
Change-Id: Ie2d8b1b1557175d45cff6b27b7291b3d2c4560df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110739
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84880}
Instead of loading {kMaxUInt32 + 1} (or 2^31) as a 64-bit constant, load
{kMaxUInt32} as a 32-bit constant. This saves four bytes on debug-code
enabled builds (i.e. mostly debug builds).
R=thibaudm@chromium.org
Change-Id: I58a5fac9f94df6cb6dbc22dfc33e191765ef0622
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096738
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84879}
This unordered map is mixing code objects and other objects, which makes
operator== unsafe to call with external code space enabled. In case a
heap object and a code object have the same compressed pointer, they
will also have the same hash value and thus must be compared with
EqualSafe.
Bug: v8:13466
Change-Id: I269c46c054d8acd3accb126d2f7d3225ef4bbfde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111640
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84878}
For bigger code blocks it makes sense to use the "scoped comments" with
an opening and closing bracket. In particular, if more such scoped
comments are already generated inside the block (e.g. for decoding the
sandboxed pointer, or for AssertZeroExtended).
Thus add scoped comments around loading from memory and storing to
memory.
Drive-by: Mark the {CodeComment} constructor V8_NODISCARD so we do not
accidentally define a temporary object that dies right away.
Drive-by 2: Remove the "#undef"s at the end of liftoff-compiler.cc; we
do not support jumbo builds any more anyway.
R=thibaudm@chromium.org
Change-Id: If4af8e9f4288529e0fe176c7f0f8376474cfa469
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096737
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84876}
My plan is to add a finch flag to the chrome side. It'll be a kill
switch, but given the history with changing the implementation, I want
to make sure we have the ability to switch back.
Bug=v8:13477
Change-Id: I1559e10d134bd78699b1119be26934570c6e5241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108811
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84874}
Three issues were fixed:
* In debug state, only publish debug code.
* When entering debugging in an isolate, only delete the code of
those NativeModules that aren't in debug state already.
* When async compilation finishes, only throw away code if the debug
state changed during compilation.
Original message:
Currently V8 recompiles all functions of a WebAssembly module when a
debugging session starts. This is outdated behavior and
causes OOMs for developers. With this CL all compiled code just gets
removed when a debugging session starts, and debugging code gets
compiled lazily.
This behavior may lead to small delays whenever a new function gets
entered by the debugger. However, developers are used to debugging code
being slightly slower, and the small delays should be in the order of
few milliseconds. On the other hand, debug modules can be big,
sometimes even more than 1'000'000 functions, and developers reported
OOMs when debugging.
R=clemensb@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ie27388a287cd16a67a483e14fc22c2ab4180962e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079190
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84873}
