During background compilation, we check
SharedFunctionInfo::HasBreakInfo() to see if the function has
breakpoints for debugging, generally deciding not to inline the
function if so. We were concerned about the status of this bit
changing on the main thread. Happily, the main thread deoptimizes
all functions that inline the given function, and shuts down all
background compilation jobs as well. So it is not a meaningful
concern (that of say, ignored breakpoints). Updated a comment to
record this finding.
Bug: v8:7790
Change-Id: I7adbc5d19fc45eb7f4df1400c33f5988d9dac58d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848409
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74183}
This will help reducing the time needed to reach a Safepoint() on the
main thread. During startup main_thread_local_isolate() is not
initialized when Heap::AllocateRaw() is invoked. Solve this by
only running Safepoint() after deserialization is completed.
Bug: v8:10315
Change-Id: I281fdbe5cebcd7946d687f56676c0d563792fde5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835714
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74181}
This adds a test variant enabling --wasm-write-protect-code-memory, and
enables it on linux64 debug and release bots.
R=machenbach@chromium.org, jkummerow@chromium.org
CC=dlehmann@google.com
Bug: v8:11667, v8:11663
Change-Id: I04f47d06d9720f7bc9e122d17b253646f2c203b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839562
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74179}
Instead of running a second pass of the scheduled graph after
effect control linearization to do machine lowering, integrate
the machine lowering reducers (MemoryLowering and SelectLowering)
into the graph assembler used by the effect control linearization.
This saves running through the graph and re-maintaining the schedule
for the second time, reducing overhead in Turboprop.
BUG=v8:9684
Change-Id: Ib0fed19089287c8e801a063333cb8404181411db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848474
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74178}
We were inconsistent in handling offsets >= 2GB on 32-bit systems. The
code was still relying on this being detected as statically out of
bounds, but with the increase of {kV8MaxWasmMemoryPages} to support 4GB
memories, this is not the case any more.
This CL fixes this by again detecting such situations as statically OOB.
We do not expect to be able to allocate memories of size >2GB on such
systems. If this assumptions turns out to be wrong, we will erroneously
trap. If that happens, we will have to explicitly disallow memories of
such size on 32-bit systems.
R=jkummerow@chromium.org
Bug: v8:7881, chromium:1201340
Change-Id: Ic89a67d38fb860eb8a48a4ff51bc02c53f8a2c2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848467
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74175}
The property kInObjectPropertiesStartOrConstructorFunctionIndexOffset
was set as relaxed due to races with the layout_descriptor
(https://chromium-review.googlesource.com/c/v8/v8/+/555210/). The
layout_descriptor was removed with the removal of double field unboxing.
We are able to turn those property's accessors into non-atomic ones
since they are set at construction time.
Bug: v8:7790
Change-Id: I25c53f0e00718cca72ba86f8475af9ecefb7ba3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843359
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74174}
It's unfortunate that there is both a LocalIsolate template parameter,
and an actual LocalIsolate class. Clean this up by renaming the
template parameters to IsolateT
Change-Id: Iecefc3eca5aeb7bbd21e78818b90f9e75cdff10f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846880
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74173}
Prior to this CL, Refs were defined through four lists:
HEAP_BROKER_SERIALIZED_OBJECT_LIST
HEAP_BROKER_POSSIBLY_BACKGROUND_SERIALIZED_OBJECT_LIST
HEAP_BROKER_BACKGROUND_SERIALIZED_OBJECT_LIST
HEAP_BROKER_NEVER_SERIALIZED_OBJECT_LIST
Due to the way FooData objects are constructed (a long if-else chain
generated from these lists), the order of entries within the lists and
also between lists was important. In particular, subtypes had to
appear before all their supertypes. Within one list this was doable,
but with the split into 4 different lists this invariant cannot hold
in practice.
This CL refactors the four lists back into a single list to make
observing the invariant possible with upcoming changes. The new
unified list contains the RefSerializationKind as a second argument.
Related changes are not very interesting, except for
TryGetOrCreateData which now uses a set of templated functor objects
for setup (this was necessary to handle different FooData constructor
signatures).
Bug: v8:7790
Change-Id: Ia4c030c767830be4253cf41e3aaf67454f1cbef6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843351
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74171}
Prior to this patch, `new RegExp('a/b')` logs the following in
the DevTools Console:
/a/b/
This is syntactically invalid.
This patch fixes this while simplifying regular expression printing
in general by leveraging `RegExp#toString`, instead of duplicating
the logic on the inspector side. This is possible thanks to the recent
work on making `RegExp#toString` more robust (v8:1982).
Bug: chromium:1202013, v8:1982
Change-Id: I14ccc1892f4a99361ad170fea608ace630740991
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848463
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74169}
On a per-job basis, --turbo-direct-heap-access should be equal to
whether concurrent inlining is enabled. We simplify involved logic by
removing the flag, and replacing all access to
- FLAG_turbo_direct_heap_access, and
- FLAG_concurrent_inlining
inside compiler/ with
OptimizedCompilationInfo::is_concurrent_inlining() (or derived values).
Bug: v8:7790
Change-Id: I64818e0e1004dded08c784ef1c4bdfd2af990a59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843345
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74166}
.. which used to be implemented by calling BooleanValue eagerly on all
seen heap objects during serialization. 1) it's wasteful to call this
on every object, 2) this was blocking conversion of HeapObjectRefs to
not require main-thread serialization.
This CL replaces the old pattern by a thread-safe TryGetBooleanValue
method, which may fail in some cases (e.g. when trying to read into a
HeapNumber).
Bug: v8:7790
Change-Id: I9d4ab7725231adce0b488c4c08c1f4bac78ce3c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839557
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74165}
.. by locking the MapUpdater lock during MapData construction.
Note this only applies to basic MapRef/MapData construction. Some
methods, in particular MapRef::SerializeFoo methods, are not yet
background-serializable in general and require more work.
Bug: v8:7790
Change-Id: I473e78c82012ab6abc5a0633a4d34c4a40a3fb77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839553
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74164}
This is the second CL in a line of two (see crrev.com/c/2835237) to
bring write-protection to the WebAssembly code space. The previous CL
changed the page permissions from W^X (only either writable or
executable can be active, but never both) to write-protection (due to
concurrent execution in the main thread). However, write-protection
still did not work, because in several places the code space is
modified without properly switching it to writable beforehand.
This CL fixes --wasm-write-protect-code-memory such that it can now be
enabled again (with potentially high overhead due to frequent page
protection switches). For that, it adds the missing switching to
writable by adding {NativeModuleModificationScope} objects (similar to
the already existing {CodeSpaceWriteScope} objects for Apple M1
hardware).
This CL also fixes a race condition between checking for the current
writable permission and actually setting the permission, by protecting
the counter of currently active writers with the same lock as the
{WasmCodeAllocator} itself. (Before multi-threaded compilation, this
was not necessary.)
Finally, this CL also changes the {Mutex} protecting the
{WasmCodeAllocator} to a {RecursiveMutex} because it can be requested
multiple times in the call hierarchy of the same thread, which would
cause a deadlock otherwise. Since {TryLock()} of a {RecursiveMutex}
never fails, this also removes the (now failing) DCHECKs.
R=clemensb@chromium.org
CC=jkummerow@chromium.org
Bug: v8:11663
Change-Id: I4db27ad0a9348021b0b663dbe88b3432a4d8d6b5
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835238
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74163}
This test produces different outputs when compiled with
gcc. It is currently failing on PPC using gcc-8, it also has
failed on riscv: https://github.com/riscv/v8/issues/174
I have also tested it with gcc-10 on x64 and it still fails.
The line numbers seem to be different when compiled with gcc
instead of clang.
As a workaround we can force the usage of macros in one line
to assure outputs are the same on either compiler.
Change-Id: I36a05d0dc62dfe66bdfcf177422836cb231284b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844666
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74162}
Since WasmToJSWrappers are on-heap Code objects, they should use
the "kCallBuiltinPointer" mechanism to call builtins.
AFAICT this only affected the call_ref instruction.
Bug: v8:9495
Change-Id: I2d55e8f2504787a8a92410868ced8d5ce63a5376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846896
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74157}
Currently the function normalizes only old sparse backing stores.
This patch removed the age check to decouple the heuristic from GC.
Change-Id: I9b7f787315b2b8facfa35358143173f7d207c8da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846897
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74156}
This is a reland of df4dae7765
Revert reason looks like an unrelated existing flake (https://crbug.com/v8/11634)
Original change's description:
> [arm] Make the constant pool check deadline smarter
>
> Rather than having periodic constant pool checks that almost always fail
> (because the constant pool deadline isn't close enough, or even because
> there's no constant pool to emit at all), set a single deadline on the
> first constant pool insertion which expires just before the maximum
> distance to the constant pool. Constant pool checks around unconditional
> jumps happen irrespective of this deadline.
>
> In particular, this is made possible by fixing the incorrect assumption
> that the constant pool can be emitted out of order. The new assumption
> (that the emission is in-order) is validated with a CHECK.
>
> Bug: v8:11420
> Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74141}
Bug: v8:11420
Change-Id: I1cc5ca9082da26ab225dee8d8ea22c385c6cc1d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848468
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74154}
We could end up in a baseline entry trampoline without having
baseline code, because of an unhandled interaction in the debugger
(discarding baseline code) and the deoptimizer.
Bug: chromium:1199681
Change-Id: Ia33bb4d64903dd989728465b3d83a88b84597a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843820
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74153}
The ToString intrinsic isn't used anymore, since there is now a ToString
bytecode, so we can remove it.
Change-Id: I5ed121ae4d117660e1ee8a64a2b30e1fb054a886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848465
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74151}
Prior to this patch, the RemoteObject for e.g. `/x/d` got a
`description` that omitted the new `d` (`hasIndices`) flag.
Bug: v8:11684, v8:9548
Change-Id: I774fbd9620c6f3f2f19b819c9009fab7cc2e3229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848460
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74148}
This CL applies the following changes:
- JSCallReducer no longer generates a CheckBigInt in front of the
generated BigIntAsUintN.
- This results in a slight change of the semantics of the latter, which
now includes the necessary type check. Typer and Verifier are changed
accordingly.
- The BigIntAsUintN operator is now effectful, since it can now deopt.
- IrOpcode::kBigIntAsUintN is now lowered in SimplifedLowering instead
of EffectControlLinearizer, the necessary type check is introduced
by the RepresentationChanger.
- Adds a small mjsunit test to check the correct deoptimization behavior
of optimized BigInt.asUintN.
==> Remove UseInfo::TruncatingWord64()!
Drive-by: Fix an issue in ChangeUnaryToPureBinaryOp when the new_input
is at index 1.
Drive-by: Introduce an %Is64Bit() intrinsic to allow tests to
distinguish 32 and 64 bit architectures.
Bug: v8:11682
Change-Id: I448f892d3bd2280d731ae5b248c833de8faf1bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843816
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74147}
This reverts commit df4dae7765.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20-%20debug/18512/overview
Original change's description:
> [arm] Make the constant pool check deadline smarter
>
> Rather than having periodic constant pool checks that almost always fail
> (because the constant pool deadline isn't close enough, or even because
> there's no constant pool to emit at all), set a single deadline on the
> first constant pool insertion which expires just before the maximum
> distance to the constant pool. Constant pool checks around unconditional
> jumps happen irrespective of this deadline.
>
> In particular, this is made possible by fixing the incorrect assumption
> that the constant pool can be emitted out of order. The new assumption
> (that the emission is in-order) is validated with a CHECK.
>
> Bug: v8:11420
> Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74141}
Bug: v8:11420
Change-Id: Ib822425749df33fb22a38d317c107a523b382e01
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846899
Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74144}
JS-to-Wasm wrappers embed heap constants (like the undefined value), and
those heap values are being accessed during compilation for tracing.
This is not a data race, since those values are read-only. But if the
isolate dies while we are compiling those wrappers, we might read from
the heap after it has been free'd.
Ideally we would not access the isolate or the heap at all during
compilation, but delaying all tracing until the "finalization" phase is
not feasible, and removing the heap value printing from tracing would
significantly regress quality of this tracing.
Hence this CL only fixes the actual issue: That we keep compiling
wrappers when the isolate is already gone. It does so by introducing an
{OperationsBarrier} per isolate that is being taken by each thread that
executes wrapper compilation, and is used for waiting for background
threads to finish before the isolate shuts down.
Additionally, we actually cancel all compilation if a module dies (or
the isolate shuts down) before it finished baseline compilation. In this
state, the module cannot be shared between isolates yet, so it's safe to
fully cancel all compilation. This cancellation is not strictly
necessary, but it will reduce the time we are blocked while waiting for
wrapper compilation to finish (because no new compilation will start).
R=thibaudm@chromium.orgCC=manoskouk@chromium.org
Bug: v8:11626, chromium:1200231
Change-Id: I5b19141d22bd0cb00ba84ffa53fb07cf001e13cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846881
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74142}
Rather than having periodic constant pool checks that almost always fail
(because the constant pool deadline isn't close enough, or even because
there's no constant pool to emit at all), set a single deadline on the
first constant pool insertion which expires just before the maximum
distance to the constant pool. Constant pool checks around unconditional
jumps happen irrespective of this deadline.
In particular, this is made possible by fixing the incorrect assumption
that the constant pool can be emitted out of order. The new assumption
(that the emission is in-order) is validated with a CHECK.
Bug: v8:11420
Change-Id: I061dd0b8c3476ba95ee1acfb3b485d8ba2adda91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844665
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74141}
BUG=v8:9684
Change-Id: Ia63928e67dd714690b4f54c14361c6ee5e81f604
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843809
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74139}
`exectionContextId` parameter in Runtime.addBinding is not working
correctly and does not have a practical use case. Therefore,
deprecating it in favour of the `executionContextName` parameter that
better serves the purpose of exposing bindings to isolated worlds. We
expect most users to be able to migrate to `executionContextName`.
Bug: chromium:1169639
Change-Id: Ic37cefa6a62501c7e903923f1f9c0da7e51326c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844652
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74137}
Untangles the non-tracing GC optimization (Scavenger) that allows for
dropping objects that are only reachable from certain API references
from EmbedderHeapTracer. Instead, allow setting it on Isolate.
This allows for using the optimization when using cppgc.
Chromium-side: https://crrev.com/c/2844587
Bug: chromium:1056170
Change-Id: I20f28dd84c808872c7f9559c8c168e828794dd1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844657
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74135}
