The zone should just be a member of {WasmModule} instead of a
heap-allocated second object.
R=ahaas@chromium.org
Change-Id: I9cf7d5145ea9131a5ae3382c6f5aa63b816d9aa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080032
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84690}
Reorder the struct definition to put fields first, then constructors,
then accessors.
R=ahaas@chromium.org
Change-Id: I9242e2f6e70b36bc62649369e9c6997d0a3d8dfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079216
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84689}
The allocator used for the signature zone in WasmModule is always the
WasmEngine's allocator. So remove the accessor and get the allocator
from the WasmEngine directly instead.
R=ahaas@chromium.org
Change-Id: Id8bf0644b7e8aabaaf1d0e246a074c17d0154bbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078964
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84688}
This is a reland of commit eeed2ebadb
Changes since revert:
- Disable test for builds that don't support shared heap.
Original change's description:
> [heap] Invoke GC callbacks in safepoint for shared GCs
>
> After a shared GC, trigger all registered callbacks while the global
> safepoint is active.
>
> Bug: chromium:1395117
> Change-Id: I16c61533d44fbeddda18414d2256203848420a99
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079624
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84653}
Bug: chromium:1395117
Change-Id: I145dadac39d81342d7fbc2bad8b87f3518b0100e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4081130
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84687}
... so that we can check that we correctly installed a maglev
code during OSR.
Bug: v8:7700
Change-Id: I6f1d12e8b43cb7c0639e75c43400c5000c090a00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078937
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84686}
The write barrier for DescriptorArray needs to handle stores into
shared objects as well. In such cases the gc epoch from the shared
heap isolate needs to be used.
This CL also adds a DCHECK that the write barrier for JSArrayBuffers
is never used for shared objects.
Bug: v8:13267
Change-Id: I15bd227bd7352913bc53c88f46353859cca3146f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079091
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84684}
Shared heap is not available without write barriers, therefore skip all
tests that require shared heap when write barriers are disabled.
Change-Id: I66a9a94941ffab792ced964f12df6930b13c92cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079120
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84682}
We import baseline push according to our needs.
Bug: v8:7700
Change-Id: I2a9d8c2453d44d2da38a9bc32247af1bc3d0c22a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080467
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84681}
Analagous to crbug.com/v8/9534, record the size of potential deopts and
include these in the stack check (so that a deopt can't overflow the
stack).
Bug: v8:7700
Change-Id: I8ca9489c5bd758506f3a0797222de3284fc0d281
Fixed: chromium:1395112
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079226
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84678}
To be able to retrieve structured stacktrace information like the
functionName of single stack frames outsite of v8, this cl adds a
V8StackFrame class and a function to retrieve them from V8StacKFrames.
Bug: chromium:1393317
Change-Id: Idae150aeb03f7b65294c4c6a6979c298a569e6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067040
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Judith Hemp <hempjudith@google.com>
Cr-Commit-Position: refs/heads/main@{#84676}
This adds new modes to run gcmole on multiple hosts:
- collect: Parse source files and store partial raw call graph in
a binary output file.
- merge: Read multiple partial call graphs stored by 'collect', merge
them and store the gc-suspect information.
- check: Use the stored suspect information to check source files for
problems.
The modes 'collect' and 'check' support sharding parameters, so that
each shard runs on a deterministic fraction of the source files.
The previous way of running gcmole locally is unchanged as 'full'
run. All modes also support the --test-run parameter, running against
a test double.
The parameter to reuse suspects is removed as the new 'check' mode
makes it redundant.
This also adds python tests to verify most additions for merging
call graphs and for distributing source files to shards.
The new API is used on the infra side via the gcmole_v3 config, which
we configure now in parallel to the previous version to test for
equality.
Based on the builders.pyl change, these additions also run on the
v8_linux_rel trybot on this CL.
Bug: v8:12660
Change-Id: Ibe66292cb00830fa1c23451081a8de4cbc4766a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075907
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84674}
This change enabled constant-folding for parseInt when input is a string constant and radix is a known value.
Change-Id: Iea105af34648077451d272958e484a20651d8013
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4060352
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84671}
Drive by: refactor framework_name propagation. The property was already injected in the TestSuite objects. Since it finally got attached to the result record it was natural to have it attached on the TestCase object at creation time. This eliminates the need to inject it through progress objects.
Change-Id: Ic4028d24589a241fb6225dc53ccef2215728d569
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079228
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#84670}
Apart from JSApiObject, there are other JS types with other visitor-ids
that may contain embedder fields. The CL adds support for embedder fields
visitation for such types.
Bug: v8:13475
Change-Id: Ifa6f947964d7900245287b35beab19f5b11347ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079015
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84669}
This reverts part of crrev.com/c/4020425, because it turns out that the
runtime call pays off for strings above a certain length.
Bug: v8:12868
Change-Id: I1c4d5a01bb0f1303c2385c7707b3e5fff6936b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075728
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84668}
We make sure the number of stack slots in the graph will yield
an aligned stack in the prologue.
We also guarantee the number of extra slots used in a safepoint is
even.
Bug: v8:7700
Change-Id: Ib59fdc5e81dc8f0cf97b7122346cb2decbc58609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079164
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84667}
MSVC has trouble with macro expansion in this case. Avoid the issue by
simply writing out 2 separate DCHECKs.
Change-Id: Ib379db95fab91ff7f29b817f1ebcad9b64806787
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4074286
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84666}
This reverts commit 7b138dd30d.
Reason for revert: Causes multiple flakes:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/22932/overviewhttps://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/41934/overview
Original change's description:
> [wasm] Compile debug code lazily
>
> 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
>
> Bug: v8:13541, chromium:1372621, v8:13224
> Change-Id: Ia36d9b8743523b1c89221c59f989268e27f6ce98
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067302
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84662}
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ic5442462d158618f2d43b8e0ebdfb90017ed378a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080034
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Owners-Override: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84665}
V8 currently has a runtime flag, turbo_compress_translation_arrays,
which causes it to compress translation arrays. However, this flag is
not enabled by default due to the time cost of the compression.
Furthermore, V8 can build without zlib, in which case the compression
code is not available.
In this change, I propose an alternative based on the observation that
translations are often nearly identical to the translations immediately
preceding them. This change introduces a new translation opcode,
MATCH_PREVIOUS_TRANSLATION, which indicates that the reader should use
some number of entries from the corresponding position in the previous
translation. This approach is fast to encode and can be decoded in place
without needing to first decompress the data into a temporary buffer.
On Octane, this change reduces the total size of all created
TranslationArrays from about 2.6 MB to about 1.1 MB, a reduction of
roughly 60%. This saves less memory than using zlib, but is also much
faster: the total time in V8.TFCodeGeneration during an Octane run
increases by 6-12 ms. For comparison, on the same machine, enabling
turbo_compress_translation_arrays increases the total time in
V8.TFFinalizeCode by 135-138 ms and causes a notable reduction in
overall score.
The benefit in memory reduction tends to be larger on larger translation
arrays. I started looking into this issue after receiving a memory dump
with a particularly large 909 kB translation array. With this change,
that translation array can be represented in 107 kB, saving 88% of the
size.
Bug: v8:11354
Change-Id: I424e107b9ab3846e7f3925a79cc018e7963db413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4071249
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84663}
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
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ia36d9b8743523b1c89221c59f989268e27f6ce98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067302
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84662}
This reverts commit 0bd121f8e6.
MemoryAnalyzer wasn't calling LateEscapeAnalysisReducer's
ShouldSkipOperation method, but instead was calling the BaseReducer's
method (because it was using a generic Operation) for the call, which
resulted in some memory corruptions, because MemoryAnalyzer was
planning some folding which was never actually happening.
Original change's description:
> [turboshaft] Port LateEscapeAnalysis
>
> Bug: v8:12783
> Change-Id: Id5fa026d103dc67e05322b725f34186124bc5936
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4054621
> Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84603}
Bug: v8:12783
Change-Id: I103eb2f518943c0c57bc3e10471d1c47f5262599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075724
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84660}
This moves validation off the main thread, and parallelizes it by
offloading validation of individual functions to a separate JobTask.
For now, we join that task after receiving the last chunk of data from
the network. At this point the main thread might participate in
validation, if there is work left to be done.
This should be further optimized to avoid any validation on the main
thread and avoid waiting for background threads to finish validation.
Instead, the background threads should trigger finishing of the
AsyncCompAsyncCompileJob. That's another significant refactoring though,
so we only do that in a second step.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I22d0545d99f02e2040d3b262f5731e75d55c14e2
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4054623
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84659}
This CL applies the following changes:
- a number of redundant DCHECKs have been removed.
- MoveToTempLocation on PPC specifically checks for Simd128
usage even though Simd and Double scratch register numbers are the
same at the moment.
- kScratchReg usage is removed from under AssembleMove in PPC.
- SetPendingMove covers F32/F64 and Simd126 stack and scratch register
usage by AssembleMove using `IsFPStackSlot` and `IsFPRegister`.
Change-Id: I7e4257bb8cc1e66d59cdabe93c113b724cf91c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4072585
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#84657}
It looks like the server-provided information changed back to what
it was before crrev.com/c/4023861, but rather than just revert that,
this patch makes the logic in our script even more robust.
No-Try: true
Change-Id: I9d60b1c61f85d9bde1275695dbd18c62fa4569bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080387
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84656}
The test-run mode was broken after output improvements and the
introduction of pathlib.
This fixes the string concatenation with paths and updates the test
output to match the status quo. This also changes the test-run mode
to run exclusively when the --test-run option is passed. Now it's
either a test run or a normal run. Like that we can add the test run
as a separate test step on a bot. If both are needed in sequence
for something, gcmole could be called twice.
Bug: v8:12660
Change-Id: I58179d50950fa76d8f66b974325a8fed84dc91b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075727
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84655}
By applying the same special-case that the Torque builtin already has
to the runtime function.
This is a quick fix pending discussion what the right long-term solution
should be.
Bug: v8:13523
Change-Id: I5303d5ac598d00189f7eb2d9d78b81ad11b919b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075527
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84654}
After a shared GC, trigger all registered callbacks while the global
safepoint is active.
Bug: chromium:1395117
Change-Id: I16c61533d44fbeddda18414d2256203848420a99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079624
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84653}
This is a reland of commit bb288ea342
Changes since revert:
- Skip added test in single generation builds (shared heap is not supported in single generation).
- Use Isolate::Current() instead of GetIsolateFromWritableObject() for strings that reside in shared space (not only if the string is actually shared).
Original change's description:
> [strings] Don't try to record/update invalidated slots in shared space
>
> Strings in shared space are always direct (i.e. they don't contain
> pointers) and therefore cannot have any recorded slots.
>
> Drive-by: DCHECK no slots are recorded in shared space.
>
> Bug: chromium:1394741
> Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84630}
Bug: chromium:1394741
Change-Id: I6889b565f8a247ae1fe553158e29984e7c05563a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079224
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84652}
This isn't enough to run proper mjsunit tests, but it's enough to
compile a simple function like:
function foo(x, y) {
return (~x | y & x ^ y) >> 1 << 1;
}
Bug: v8:7700
Change-Id: Ied109e3e1d841156c964999d6d961644c943bc8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080226
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84651}
To handle stack overflow correctly, we need to check for stack overflow
during calls in the caller, before pushing too many arguments onto the
stack.
Handle this in Maglev same as in TurboFan and Sparkplug -- calculate the
maximum size of calls, and use this in the function entry stack check,
rather than checking on each call.
Bug: v8:7700
Change-Id: I521bee3f5386d5100f94142a5054eb9a1434284a
Fixed: chromium:1384403
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079009
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84650}
This (micro)optimizes data dependencies of gcmole in two ways:
1. Only bundle icu folders 'common' and 'i18n', omitting particularly
icu's data and test folder, which aren't needed for running gcmole.
This reduces gcmole bundle size from 377MB to 239MB, reducing upload
and download times by a few seconds on g1 bots.
2. Process gcmole data dependencies during GN time only when gcmole
is configured via gn flag. Currently, the dependency files are also
processed on all other bots that aren't running gcmole.
Bug: v8:12660
Change-Id: Ib708fa2957e6e33698e51b2aee45929f4d467935
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076331
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84648}
The evacuation threads can't use isolate()->fuzzer_rng() directly
since this class isn't thread-safe. This CL uses this RNG to create
thread-local RNGs for each evacuation thread.
Bug: v8:13549
Change-Id: I3a71617e494ae63fcebc2bab2ee2d7a7714de7bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078965
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84647}
The OnProfileEndListener callback has to be reset before the isolate
dies to avoid a use-after-free when the Global which holds the callback
gets released.
Drive-by change: make the OnProfileEndListener callback
isolate-specific. At the moment a `profileEnd` call in IsolateA could
trigger the OnProfileEndListener callback of IsolateB, which could
cause all kinds of data races (the callback would access the isolate,
but the isolate is not supposed to get accessed by multiple threads
concurrently. With this CL there is one callback per isolate.
R=clemensb@chromium.org
Bug: chromium:1395237
Change-Id: Ifaa5b883a231f5519a3bfeb6187fb7d8faa02b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076465
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84646}
This is a reland of commit 347142f647
This CL fix a bug for bolck onclick event, and improve compatibility
for old turbo-x.json files.
Original change's description:
> [turbolizer] Show basic block id in schedule phase
>
> In the schedule phase of turbolizer, there is only RPO number was
> shown, when we want to debug Builtin PGO or other modules, we
> would like to see the block id instead of RPO number.
>
> this CL add the support for displaying basic block id for schedule
> phase in turbolizer.
>
> Change-Id: I7a71f259230564400b683d598f68b6d064f1eb4d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068103
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84625}
Change-Id: Ibaee4826678169d65e809bcad1e29587e480663f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4073861
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Cr-Commit-Position: refs/heads/main@{#84645}
The fuzzers based on {WasmExecutionFuzzer} (wasm-code, wasm-compile)
were already switched over in https://crrev.com/c/4042288.
The wasm-async and wasm fuzzers were still testing against the
interpreter, even though WasmGC opcodes are enabled, which leads to
crashes due to incomplete interpreter support.
This CL now switches those remaining fuzzers to "liftoff as reference"
mode, and removes support for testing against the interpreter.
As Liftoff code runs a lot faster than the interpreter, we bump the
limit for the number of executed instructions from 16k to 1M.
R=jkummerow@chromium.org
Bug: chromium:1387316, chromium:1393379, v8:13496
Change-Id: Id3e6177cc89b49e69d03515f10eedaf0872bde82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078983
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84644}
For some reason, {OwnedVector} defines both a {start()} and a {begin()}
accessor which return the same value. As {begin()} is the name that the
standard library uses, this CL removes {start()} and switches all uses
to {begin()}.
R=mslekova@chromium.org
Change-Id: Ib505fe146db396f7589404c5a630e19248624729
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075865
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84643}
We already check that if streaming decoding fails, then also synchronous
decoding finds an error. This adds a DCHECK for the other direction: If
streaming decoding succeeds, then also synchronous decoding must
succeed.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Iade188ee81b6d3df964f35777d1d3a71350a6811
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4071924
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84642}
The wasm export wrapper passes the expected type as a Smi parameter to
the {WasmJSToWasmObject} runtime function. However, since this wrapper
might be compiled by a different module that is currently running it,
it is not enough to pass the module-specific type index and the module
to reconstruct the type. Rather, we must pass the canonical type
index.
Bug: v8:7748
Change-Id: I84e34e855898477a135f213f07bca10e95ecf49a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068123
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84641}
