This reverts commit 02e5787389.
Reason for revert: High flakiness and broken GPU builders. See:
https://crbug.com/v8/10178
(speculative revert)
Original change's description:
> heap: Delay completing marking
>
> Delay completing marking (and thus the atomic GC pause) during JS
> executions, increasing the chance to finalize the garbage collection
> from a task. This is beneficial as it avoids stack scanning which is
> expensive and can keep alive outdated objects in case of unified heap.
>
> Completing will be delayed at most by some overshoot factor (10%).
>
> In addition, the GC keeps the weighted average of previously recorded
> time to incremental marking task invocations and bails out if the
> task is expected to arrive too late.
>
> Bug: chromium:1044630
> Change-Id: I10e63e6aaa88d8488d4415f311016dce2b4e62a2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030906
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66107}
TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
Change-Id: I0cd3f1189d0f83754350d5bdaaf82cb3c4d402c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1044630, v8:10178
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037434
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66120}
This relands commit 5cfe053e45.
Original change's description:
> [wasm-simd][liftoff] Add S128 case for stack movements
>
> The two cases we are fixing here are Construct and
> LoadCallerFrameSlot, which are closely related.
>
> Construct is called during PrepareCall, where we build up
> LiftoffStackSlots when we need to move an arg from caller's stack frame
> into callee's stack frame. LoadCallerFrameSlot is the parallel to
> this, called in ProcessParameter during decoding of the callee's
> function body.
>
> In most cases, Construct needs a new case to handle kWasmS128, and calls
> the relevant assembler to push a s128 onto the stack.
>
> ARM64 requires 16-byte alignment of sp, so we need to Claim the right
> number of kXRegSize slots first, which requires
> us traversing the list of slots to figure out how many s128 values there
> are. This is a straightforward way to fix this, if efficiency is a
> problem, we can change LiftOffStackSlots::Add to sum up the slot sizes.
>
> On IA32, pushing s128 values will require 4 calls to push. Instead, we
> use a sub and two movdqu, which will generate less code in most cases.
>
> On x64, there is no 128-bit push, so we call push twice.
>
> Bug: v8:9909
> Change-Id: I3af35b8462ea9c3b9b2d90800c37d11b5e95be59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015945
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65956}
Bug: v8:9909
Change-Id: Icdaead289abe13faf75bb9e049929f7fd7c59a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036760
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66119}
Ensure that the top tier streaming callback is called, even when the
native module is actually fetched from the cache rather than compiled.
This preserves the old behavior, such that the cache stays an
implementation detail to clients of the streaming compilation API.
R=clemensb@chromium.org
Bug: v8:10165
Change-Id: Ib243c97529900f76b7b9cd5d1d57f259bc38225c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035875
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66117}
"Remove the JSON parser and revamp Value::parseBinary."
Upstream review: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2026351
In addition to the upstream changes, this PR includes the necessary
tweaks to the V8 inspector (now taking the detour via
CBOR to parse Javascript).
New Revision: 0e0a1995497511008864546c094e885f3f1e13a3
Change-Id: I5ccfea5a3e1bab3e183b45c87726747d17d06944
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020518
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66116}
When not being embedded, there's no need to try to share time with the
embedder.
Additionally, avoid too small step sizes.
Bug: chromium:1044630, chromium:1048631
Change-Id: I227bfd120b5ce1976935d27c2140263f7364eb51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036085
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66115}
This will allow uploading repro test cases to clusterfuzz for
already suppressed known issues. This will allow tracking if those
issues still reproduce and that suppressions don't become stale.
No-Try: true
Bug: chromium:1044942
Change-Id: I997f11293c51836b97d143b0fea992055b39955e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036083
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66114}
Change the TPH API so that it uses v8::internal::Isolate rather
than v8::isolate.
The third party heap is within the internal namespace and ultimately
needs access to v8::internal::Isolate to do things such as adding code
ranges. There's no reason for it to use v8:Isolate.
Bug: v8:9533
Change-Id: I8c3ecd6278081f03133013d4e3b02fb3ed228baf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036088
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Cr-Commit-Position: refs/heads/master@{#66113}
The debug side table is indexed by pc offset. Offsets change if
breakpoints are added or removed, hence we cannot reuse the debug side
table when compiling another version of the function (with a different
set of breakpoints). Thus store the debug side table per code object
instead of per function.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ifd77dd8f43c9b80bc4715ffe5ca8f0adca2aaf42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030922
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66110}
This is much faster than std::lexicographical_compare.
R=clemensb@chromium.org
Bug: chromium:1048554
Change-Id: I5f0ba22654e172535b6e6fcf6d2a460e278d3cfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036078
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66109}
These guards are needed since the third part heaps don't use the
deserialization reservation system.
Bug: v8:9533
Change-Id: I0e8bd7928581979bed15abdfaf639c9fdfc8a30f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030908
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66108}
Delay completing marking (and thus the atomic GC pause) during JS
executions, increasing the chance to finalize the garbage collection
from a task. This is beneficial as it avoids stack scanning which is
expensive and can keep alive outdated objects in case of unified heap.
Completing will be delayed at most by some overshoot factor (10%).
In addition, the GC keeps the weighted average of previously recorded
time to incremental marking task invocations and bails out if the
task is expected to arrive too late.
Bug: chromium:1044630
Change-Id: I10e63e6aaa88d8488d4415f311016dce2b4e62a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030906
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66107}
TracedReference is supposed to be as light-weight as possible without
destructor or other callbacks, essentially just representing a plain managed
reference.
Change-Id: Iae52cf7460e3623f1fb7d183757ecd39b2431369
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033173
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66106}
This CL templatizes some methods in BigInt on the Isolate type, to allow
BigInts to be allocated off-thread from a BigInt literal.
A necessary side-effect is exporting the Isolate class in its entirety,
to allow it to be used as a specializing type for ' HandleFor' in
unittests.
Bug: chromium:1011762
Change-Id: I768f9e4d46a4532d6818d9a67c13801bc5952e5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036079
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66105}
Different contexts have different header sizes now.
The function ScopeInfo::ContextHeaderLength should be used instead of
Context::MIN_CONTEXT_SLOTS.
Bug: chromium:1021884
Change-Id: Ia9ea321cfb19d2a2ae0bc12c7db621f7d35b3b51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036074
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66103}
This is mostly used for regression tests which don't need that function.
If we want to wrap it for inclusion in an existing test file, we can
easily add a function around it, and name it properly.
R=ahaas@chromium.org
Bug: v8:10177
Change-Id: I2aedcdfad09fe1fe07af9f0caa2b8bd45da902f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036077
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66102}
The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).
However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.
Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.
Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).
Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
Respective differences were fixed and the suppressions didn't fire
anymore according to the statistics.
No-Try: true
Bug: chromium:664068, chromium:667678
Change-Id: I5e1aa802e0b0288a73d0f236c154289ab45314a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035878
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66100}
This makes the output of --wasm-fuzzer-gen-test more useful by adding a
comment at the end of each line. This prevents clang-format from
breaking up individual lines.
R=ahaas@chromium.org
Bug: v8:10177
Change-Id: I222f7e30c84712357159e837e8b2e36737696669
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036076
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66099}
This changes how we setup modules from being entirely bytecode based to a
single fixed array with metadata that's passed into a runtime function
DeclareModuleExports, similar to DeclareGlobals. This is preperatory work to
replace the bytecode that calls those functions with explicit calls before we
even start running the code. In the case of modules that will obviate the need
for modules to be generators.
Change-Id: Ibf1c913a9dc78041e3001b174c66ab89226d9c8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030733
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66097}
This method was used to implement deserialization via the value
serializer. It was deprecated since this functionality is not used any
more, and hence untested.
This CL cleans up by removing the deprecated method and two private
helper methods.
R=adamk@chromium.org
Bug: v8:10155
Change-Id: I4dda1949fd4f1b499cb6f8d6e6a76b642179303a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033171
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66096}
If we need a byte register, but {src} is none, we should definitely use
another register.
R=ahaas@chromium.org
Bug: chromium:1048241
Fixed: chromium:1048241
Change-Id: I3396826986e1823250ad6855b84f4b05faaf3b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036073
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66095}
When the embedder integrates in V8's garbage collector the performance
of the atomic phase is sensitive to how much embedder memory is found
through marking the overall transitive closure.
Before this patch, V8 would help out tracing the embedder's heap when
making progress through tasks but not on allocations. In addition, V8
would complete the garbage collection when it has observed it's own
marking worklists as empty 3 times (*). This can create performance
cliffs when there's a lot of work still to be done on the embedder
side.
This patch adds helping steps on allocation that are proportional to
the bytes that V8 would otherwise process, guaranteeing some progress
as long as there's V8 allocations. This allows us to remove (*).
Potential Tradeoffs:
- More time spent in V8's garbage collection metrics as we slightly
limit the chances for the embedder to mark objects through tasks.
- Prolonged V8.execute time (JS execution)
+ Faster progress
+ Less memory
+ Smaller atomic pause time
Change-Id: I160f063209f7e129b9c884206f833706b69dadc1
Bug: chromium:1044630
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025371
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66091}
This relands commit 7c32fa05df.
Some test cases need to be updated, since we will bail out to TurboFan
where previously Liftoff was happy to run, when SIMD is not supported.
Original change's description:
> [wasm-simd][liftoff] Check CpuFeatures for SIMD support
>
> If Wasm simd128 is not supported on this particular hardware, we bail
> out to TurboFan.
>
> Bug: v8:9909
> Change-Id: Ie46e154426783ba099b7c0facc906670cda1bdd0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029427
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66055}
Bug: v8:9909
Bug: v8:10169
Change-Id: I850e1fe6bfbd12fb2eec052aa8367624c09f7a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030354
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66090}
After allowing larger strings on 64-bit builds, this test OOMs on
Android devices that don't have enough memory.
Tbr: machenbach@chromium.org
Change-Id: I05c44d7074388a4306e5266ba1aa9da760c83377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035877
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66089}
The assembly of sqrtpd when using Sqrtpd macro was wrong, since
Sqrtpd(xmm1, xmm1) will incorrect generated vsqrtpd(xmm1, xmm1, xmm1),
which is nonsensical, since vsqrtpd only takes two operands. The
expected instruction should be vsqrtpd(xmm1, xmm0, xmm1) in terms of the
encoding, which is vsqrtpd(xmm1, xmm1).
So, move sqrtpd and cvtps2dq out into their own macro list, because
they have two operands in their AVX form, unlike the rest of the
instructions in SSE2_INSTRUCTION_LIST.
Also updated disasm and tests to use this new list.
Fixed: v8:10170
Change-Id: Ia9343c9a3ae64596bbc876744556e1dcea2a443b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032195
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66088}
The implementation is pretty much the same, and we instead delegate to a
macro assembler to decide if we want the sse or avx instruction.
This unification will simplify optimization of constant shifts later on.
Bug: v8:10115
Change-Id: If9a17519a746f0a8474e75dbdebb8e4f5b0d07c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026469
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66087}
test-run-wasm-simd/RunWasm_S8x16MultiShuffleFuzz_turbofan was failing
reliably with --no-enable-avx. (Even though the shuffle sequences were
randomly generated, in practice we quite quickly hit a case where we
will get a segfault.)
For 32x4swizzle and 32x4 shuffle, they use pshufd, which can take an
operand, but needs to be 16-byte aligned, which they are not, current.
So force them to be registers for now. This is similar to what we do in
the x64 selection too.
Bug: v8:9198
Change-Id: If319ff276202d4be095714a6cb18dec0d0551efd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032202
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66086}
Crashes in the presence of RangeError happen often during differential
fuzzing. Until now we have ignored such cases completely.
After this change we compare as much output as possible when one or
both runs have crashed, dramatically increasing the coverage.
No-Try: true
Bug: chromium:1048099
Change-Id: I923c10e9064b5dc6cae1e39a254e221d2867e0e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030914
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66085}
This CL implements functionality to allow an embedder to mark a
debug scope as terminate-on-resume. This results in a termination
exception when that debug scope is left and execution is resumed.
Execution of JavaScript remains possible after a debug scope is
marked as terminate-on-resume (but before execution of the paused
code resumes).
This is used by blink to correctly prevent resuming JavaScript
execution upon reload while being paused at a breakpoint.
This is important for handling reloads while paused at a breakpoint
in blink. The resume command terminates blink's nested message loop
that is used while to keep the frame responsive while the debugger
is paused. But if a reload is triggered while execution is paused
on a breakpoint, but before execution is actually resumed from the
breakpoint (that means before returning into the V8 JavaScript
frames that are paused on the stack below the C++ frames that belong
to the nested message loop), we re-enter V8 to do tear-down actions
of the old frame. In this case Runtime.terminateExecution() cannot be
used before Debugger.resume(), because the tear-down actions that
re-enter V8 would trigger the termination exception and crash the
browser (because the browser expected the tear-down to succeed).
Hence we introduce this flag on V8 that says: It is OK if someone
re-enters V8 (to execute JS), but upon resuming from the breakpoint
(i.e. returning to the paused frames that are on the stack below),
generate a termination exception.
We deliberated adding a corresponding logic on the blink side (instead
of V8) but we think this is the simplest solution.
More details in the design doc:
https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
Bug: chromium:1004038, chromium:1014415
Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66084}
Without pointer compression, the max string length on 64-bit platforms
used to be 2**30 (minus header). With pointer-compression, this was
accidentally lowered to 2**28 (which is the historical limit for 32-bit
platforms). This CL bumps the limit on 64-bit platforms to 2**29, which
is the maximum we can support given that any heap object's size in bytes
must fit into a Smi (which are now 31-bit on all 64-bit platforms, with
or without pointer compression).
Change-Id: I263544317d9e6137f6b6a044784a21f41a2761b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030916
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66083}
This is a reland of 9781aa076f
Original change's description:
> Reland "[wasm] Cache streaming compilation result"
>
> This is a reland of 015f379aa1
>
> Original change's description:
> > [wasm] Cache streaming compilation result
> >
> > Before compiling the code section, check whether the
> > bytes received so far match a cached module. If they do, delay
> > compilation until we receive the full bytes, since we are likely to find
> > a cache entry for them.
> >
> > R=clemensb@chromium.org
> >
> > Bug: v8:6847
> > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66000}
>
> Bug: v8:6847
> Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66047}
Bug: v8:6847
Change-Id: I272f56eee28010f34cc99df475164581c8b63036
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030741
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66081}
Similar to other stack references they don't need to be scanned on incremental
marking start.
Bug: chromium:1046277
Change-Id: I9fb3ee768df0288b5a61f09e680e321a8cb7b895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030915
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66080}
When enabling tracing with the debugger 'trace' command, enable logging
everything instead of just disassembly and general purpose registers. This is
not only more useful but also consistent with the --trace-sim flag.
Change-Id: I4537ceed30edc63f4b3f39f1958ebef0cb303bf1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033172
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#66079}
This moves several simple StateValuesAccess methods as well as
SparseInputMask::InputIterator::IsReal into their header files so they
can be more easily inlined. This gives about a 7% improvement to the
BackgroundSelectInstructions runtime call stat.
Also marks some methods called by the new methods as V8_PRIVATE_EXPORT
so component build test can build.
Bug: v8:10051
Change-Id: I3e34977a4fa660d3f4f55fd4f2c0b2370d5d2bc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023559
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66078}
Rolling v8/build: 96fd652..7e7da8b
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a66ca23..0b01653
Rolling v8/third_party/depot_tools: ae510e8..906bfde
Rolling v8/tools/clang: 23191fa..80ad0bd
Rolling v8/tools/luci-go: git_revision:37a855b64d59b7f079c9a0e5368f2757099d14d3..git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711
Rolling v8/tools/luci-go: git_revision:37a855b64d59b7f079c9a0e5368f2757099d14d3..git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711
Rolling v8/tools/luci-go: git_revision:37a855b64d59b7f079c9a0e5368f2757099d14d3..git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711
TBR=machenbach@chromium.org,tmrts@chromium.org
Change-Id: Ib1ff1120322bf8fa515b41f548693f79fa9c32ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031825
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#66075}
Define a macro in code-generator-x64 to help identify cases when the
shift value is an immediate/constant. In those cases we can directly
emit the shifts without any masking, since the instruction selector
would have modulo-ed the shift value. We also don't need any temporaries
in this case.
This is only x64 codegen, optimizations for other archs will come in
future patches (and will probably look very similar to this).
The current test case passes the shifts as an immediate, so we add a new
path that loads the shift value from memory, thereby exercising the
slower path of non-immediate shift value.
Bug: v8:10115
Change-Id: Iaf13d81595714882a8f5418734e031b8bc654af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026067
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66074}
This relands commit e8832647b6.
The flaky test failures seems to be related to tiering, Liftoff
generating different call descriptors from TurboFan when Simd128
is unsupported (since TurboFan will lower the graph, but Liftoff
can continue running simd-call.js just fine).
We temporarily disable tiering for this test, until we get a proper fix,
like https://crrev.com/c/2029427/, but that fix requires this change
since more tests will fail without the lowering fixed.
Bug: v8:10169
Bug: v8:10154
Original change's description:
> [wasm-simd] Fix scalar lowering of kParameter
>
> Lowers the call descriptor of a wasm function if it contains simd.
>
> Also fixes a couple of issues with the lowering of kParameter:
> - the old_index == new_index check is incorrect, it would only work if
> the s128 parameter is the first parameter
> - the old_index was also not adjusted to account for Parameter[0] being
> the wasm instance object
> - new_index needs to be adjusted to account for the instance object too
>
> These fixes make it more similar to the lowering of kParameter in
> int64-lowering.c.
>
> Also add a new mjsunit test to exercise this logic.
>
> Bug: v8:10154
> Change-Id: Ia767a464c26a6a78fd931eab9e6897890a0904e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020521
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66032}
Change-Id: I1e27825025aefc5a42aeeb87d0447d6594388fa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029147
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66072}
We will use this state in devtools via the inspector to indicate
whether a thread is currently stuck polling in atomics.wait.
VMState already distinguishes the important states we care about which
are idle vs. running JS. We also want to know the state for
atomics.wait(), which is commonly used in WebWorkers to poll the main
page for work to do.
This CL just adds and maintains the state and adds assertions in
atomics tests. Another CL will emit inspector notifications when the
VMState changes in a way that the inspector cares about.
Re-flow comments as a drive-by cleanup.
Bug: chromium:1025490
Change-Id: I961051bfb846aa20454a56214310370ea8e47d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033168
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66071}
