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}
The `rep` field of ComparisonOp and EqualOp should be used to know
what is the representation of the things that are being compared,
rather than the output representation: the latter should always be
Word32.
Fixed: chromium:1395737
Bug: v8:12783
Change-Id: I01d29dd598da57bab3410f4b59e407e89871f207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079223
Auto-Submit: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84638}
This refactors how we generate any decoding errors during streaming
compilation: Instead of generating an error message, we only remember
that decoding failed. After all bytes have been received, we then
synchronously re-validate the bytes. This ensures consistent error
messages between all decoding and compilation pipelines.
In order to achieve this, we now unconditionally store the full wire
bytes in the {StreamingDecoder}. This partially overlaps with the
section buffers that we already store, but we cannot continue filling
section buffers after a decoder error. This will be cleaned up in a
follow-up CL.
We can also remove most of the buffer-offset tracking, which will also
be done in a follow-up.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I1d506356de6a0070c3bf2b26470dbf781f4f62e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4066922
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84636}
The chromium-side histogram is being deprecated in
https://crrev.com/c/4076250.
This CL removes the v8-side counter together with the `kAfterBaseline`
sampling mode.
R=ahaas@chromium.org
Bug: v8:12852
Change-Id: If7960824264dfc7e99e0c5c436de1dca90fbce4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076167
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84635}
When stopping incremental marking in IncrementalMarking::Stop we can't
blindly reset is_marking_flag_ for worker isolates as incremental
marking in the shared heap might be running at that point.
Since we are already here add a isolate() accessor to
IncrementalMarking.
Bug: v8:13267
Change-Id: Icb63306eef820577d59c6ca833429c1be00d294c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061322
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84634}
... which is an alias for __attribute__((const)) when it's available.
Bug: v8:7703
Change-Id: Ic585f48bc764ccf0c920ff82ba788cf1e88e0cdd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076525
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84633}
This reverts commit bb288ea342.
Reason for revert: Failing on linux debug and TSAN run
- https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20single%20generation/7820/overview
- https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/22912/overview
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: I938dcac9cb5c9154ec9a3c5504b29f3208e3e369
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079145
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84632}
The safepoint is already initiated by the HeapObjectIterator. In
addition the CombinedHeapObjectIterator wasn't updated for the shared
heap and always used an IsolateSafepointScope which didn't match the
global safepoint initiated by HeapObjectIterator.
Simplify this by relying on the safepoint scope in HeapObjectIterator.
This CL also moves the verification that all client isolates are
fully deserialized into the GC.
Bug: v8:13267
Change-Id: I59eff66a38fd8ecd8e90f68e6ed5abc5d2d4cec9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076332
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84631}
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}
This reverts commit 347142f647.
Reason for revert: <There is a bug for onclick event.>
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: If6b3674e7bc333be7d323714e3d2ca5327826892
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078511
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84629}
1) When transferring ArrayBuffers, retain resizability
2) Fix transmitting TypedArray flags; we cannot set the flags after
TypedArray creation, since the map would then be wrong.
Bug: v8:11111
Change-Id: Ic2fa3e6a4db1cb82a3751d2b114353fb477a54c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4064463
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84628}
This is a reland of commit af3678d122
Original change's description:
> [riscv] Add tracepoint instructions to help simulator debug
>
> Change-Id: I92f2c8600ab6ff2be3c0566f8dd5602cb47252cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4050059
> Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
> Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
> Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
> Cr-Commit-Position: refs/heads/main@{#84441}
Change-Id: If021236afa7f890123f95716e6ed622617b91b07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4074457
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#84627}
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}
