[*] Update default flags to internalize/canonlize more heap resources across isolate boundaries using the gross singleton hack
[+] Added padding before the embedder name in the version string
[-] Remove brand check from snapshot. Assuming this branch can only compile under my scripts, this isn't the place to worry about broken resource compiler actions. This is just going to pointlessly block trivial branding experiments. Gonna assume the nested blob we're linked against is fine.
(Last aurora commit: a27f18e3)
- 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}
This change reduce the TruncateInt64ToInt32 and BitcastWord32ToWord64 pair at machine operator reducer, since the upper 32 bits are not important.
With this change, a reduncant mov can be avoid e.g. at,
// script
function func() {
a = [];
for (j = 0; j < 13; j++) {
a[j] = j + 1;
}
return a;
}
// Assembly
// ...
movl rdi,[r8+0xb]
movl rbx,[r8+0xb] // can be removed
REX.W movq r9,rdi
sarl r9, 1
// ...
Change-Id: I6a128d9606c093df50fe9286201c1b979900864d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4115155
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84945}
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 is a reland of commit 833731b20b
Original change's description:
> [maglev] Fix %OptimizeOsr when called from Maglev frames
>
> 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}
Bug: chromium:1400549,v8:7700
Change-Id: I79fadaa0a82314a3fdd4970e9429d83ab06aff09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111950
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84938}
There is no need to park the main thread while waiting for
concurrent tasks to finish. In case they allocate threads know from
the TEAR_DOWN state and the shutdown flag in CollectionBarrier that
no further GC is going to happen.
Bug: v8:13267
Change-Id: I19f8cf8a71c2fb91618ed0be5ab82cf134edb9ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111446
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84936}
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}
