- Changes javascript builtins to use explicit parameters rather than
variadic, where possible.
tbr=tebbi@chromium.org
Bug: chromium:1085370
Change-Id: I84f01684729b32a9d27df3d021e72c34cc3a8aaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215225
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68079}
Implement all v8x16 v16x8 v32x4 all_true on ia32 and x64. arm and arm64
bailout for now, will be implemented later.
Bug: v8:9909
Change-Id: Icea38c00e33b387191e000b64100251525d8f8da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220446
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68077}
Implementation for for arm and arm64. For arm64, differ from TurboFan
implementation slightly, we don't need to the lane formats to match up,
V4S will work for all the anytrues, this makes the code slightly simpler
(no need to take the vector format as argument).
Bug: v8:9909
Change-Id: I2f40b56e816200f0f29ca151a8d6652e973350bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216933
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68076}
This CL is an initial attempt to reuse BoundedPageAllocator for cppgc.
The caged 4GB heap is needed for:
- fast implementation of the generational barrier;
- potential pointer compression project for Oilpan.
Bug: chromium:1029379
Change-Id: Idfb0ab92c988e2045d4a0e9746bedf841d66e282
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215818
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68074}
Unreachable code may consume values from an empty stack as needed, known
as stack polymorphism. After consuming the values, the stack height
should still be 0, which was incorrectly handled by multi-value blocks.
R=ahaas@chromium.org
Bug: chromium:1085507
Change-Id: Ibf5f2d05bec0fbe029cfa66ee2d07540a370934a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218033
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68070}
Adds a --streaming-compile flag to d8 so that we can test the streaming/
background compilation (e.g. for performance testing).
This differs from the --stress-background-compile flag in two main ways:
1) It's not a stress test, so it doesn't run a main-thread compile
for verification, and
2) It uses the "proper" API, and (like Chromium) pumps the message
loop while waiting for compilation to complete, so e.g. GC idle
tasks can run.
Change-Id: I1ea1badf39d25076d95c8d19f173510da277541f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219937
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68069}
We currently try to compile more deterministically in single threaded
mode, which unexpectedly degrades performance due to repeated publishing
of single compilation units. We should only pay this cost in predictable
mode.
R=clemensb@chromium.org
Change-Id: I7eb06a0849d3001b99d057adec9850810a1d6a63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218288
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68067}
This avoids a warning by clang-tidy's modernize-use-nullptr.
Bug: v8:10488
Change-Id: I2820c7e5223101c5e3f7122d2a6a3526d36851e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218063
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68065}
This is a reland of dfdef88547
Original change's description:
> [wasm-simd] Fix extract lane unsigned extend
>
> The interpreter is missing a static cast when extracting lanes smaller
> than int32_t and doing an unsigned extend. The array in Simd128 is
> signed, so a direct cast to uint32_t will be a signed extension. The fix
> is to, in the unsigned case, cast to unsigned (of the appropriate size)
> first, then cast to uint32_t.
>
> Change-Id: Ifabb5b9690f08ad505ac94b84908db0970581818
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216721
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68029}
Change-Id: Ica7974a2f1f2a4f07b54cc68f9abcf5e121a9262
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219414
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68063}
This reverts commit e1b29ce738.
Reason for revert: The blink_web_tests have been failing for a long time, without turning the bots red. Reverting the revert.
Original change's description:
> Revert "[Promise.any] Re-ship Promise.any"
>
> This reverts commit 560a681f34.
>
> Reason for revert: Suspected cause of Blink web_test failures:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4945
>
> Original change's description:
> > [Promise.any] Re-ship Promise.any
> >
> > The previous attempt failed because it uncovered an unrelated bug
> > (v8:10560). There are no known problems.
> >
> > Bug: v8:9808
> > Change-Id: I360917c45d95ba39c8bea80114ea02bc5e1f83ee
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219936
> > Commit-Queue: Marja Hölttä <marja@chromium.org>
> > Reviewed-by: Shu-yu Guo <syg@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68048}
>
> TBR=marja@chromium.org,syg@chromium.org
>
> Change-Id: I0c60e1c230932a8d06bbdd193e8de792e5f54055
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:9808
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220325
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68055}
TBR=bbudge@chromium.org,marja@chromium.org,syg@chromium.org
# Not skipping CQ checks because this is a reland.
Bug: v8:9808
Change-Id: I9d60a5476ec9b027038e0935fa26265cf5122573
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220330
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68062}
Split platform into a process-global initialization part and per-heap
platform objects.
These platform objects still contain allocators and executors. With
per-heap platforms GetForegroundTaskRunner() returns by definition the
correct runner.
In future, when initialized throuhg V8, an adapter can be used to
translate between the different platforms, avoiding the needed for V8
embedders to provide additional information.
Bug: chromium:1056170
Change-Id: I11bdd15e945687cfbdf38cae4137facb02559e0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218030
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68059}
Rolling v8/build: 99ffd3c..8275366
Rolling v8/third_party/aemu-linux-x64: 4xEEbuyLmLA-dGdzewQlaM2km7fPUiGEEdIQJhIK8v4C..FFXalyWh9_tNZ0e_Opz7FT6mJn6JW0S2ULAX3bOp0xIC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ae2ed9f..616e38c
Rolling v8/third_party/depot_tools: 8f6bfe3..4504fd5
Rolling v8/third_party/googletest/src: a09ea70..011959a
Rolling v8/third_party/zlib: 94df8b7..f5eca0d
Rolling v8/tools/clang: e34638c..8b9091f
Rolling v8/tools/swarming_client: 7e86362..90c5e17TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I8f6a76975cb22d68963f5bf2ebbeef9b33a5c959
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219819
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@{#68058}
This prepares using ochang_js_fuzzer with foozzie. The fuzzer uses
tests from CrashTests in the corpus. This leads to a loop when
used with differential fuzzing, as foozzie dedupes failures based
on the original file path. Foozzie finds a new failure for the
existing failure in CrashTests, for which clusterfuzz creates a new
crash test and so on.
This subsumes all failures from CrashTests under the same key.
Once such a failure is reported, a developer can add it to a
mapping in foozzie.py, after which the global key can be used
again by clusterfuzz to report another failure.
No-Try: true
Bug: chromium:1044942
Change-Id: I801a23faeb0c672d6ad64b4100c463f53e36cbc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214837
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68053}
Allocating a new feedback vector happens in two steps: We create an
empty structure and then initialize the array based on the
FeedbackMetadata.When allocating a new feedback array we could trigger
a GC which might flush the bytecode and associated feedback metadata.
This shouldn't happen in normal cases, because we either allocate
feedback vector after compilation or when we reach the expected budget.
In both cases, the age of the feedback vector should be 0 and hence
bytecode shouldn't be flushed. However, with debugger enabled we may
allocate feedback vectors even when the bytecode array is old
for example: when we enable precise invocation counters. This also
causes issues in tests with --stress-flush-bytecode. In the stress mode
we flush bytecode without considering the age. Holding on to the
feedback metadata prevents crashes in such cases.
Bug: v8:10560
Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68052}
This reverts commit e270b6d615.
Reason for revert: V8 DEPS roll stuck https://crbug.com/v8/10567#c1
Original change's description:
> Roll ICU from 65.1 to 67.1 (f2223961) & correct tests
>
> Rolling to chrome/src is in
> https://chromium-review.googlesource.com/c/chromium/src/+/2155530
>
> Since auto rolling stop after 3/24/2020 and the rolling will cause
> change of test status, I get this cl ready (but not running trybot due
> to 1074260) and plan to hand roll after the submission of 2155530.
>
> Bug: chromium:1064326, v8:9515, v8:10379, v8:10380, v8:10437
> Change-Id: I19554f68cfdc5b717dfc7fc4b1222e9dc25b8d69
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158486
> Auto-Submit: Frank Tang <ftang@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67493}
TBR=jkummerow@chromium.org,machenbach@chromium.org,jshin@chromium.org,ftang@chromium.org,syg@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1064326, v8:9515, v8:10379, v8:10380, v8:10437
Change-Id: I3f4233815ed7414f2cde3d4d996696575b5f6e3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219334
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68051}
Making them private was a way to hide the constructor, we can
explicitly delete them, which give a better compilation error message as
well.
Also see: https://stackoverflow.com/q/55205874
Bug: v8:10488
Change-Id: I1c037a501c1da39f027c071e5e64d36fd1c95c6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219419
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68049}
The previous attempt failed because it uncovered an unrelated bug
(v8:10560). There are no known problems.
Bug: v8:9808
Change-Id: I360917c45d95ba39c8bea80114ea02bc5e1f83ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219936
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68048}
Temporarily disable stress-bytecode-flush on
mjsunit/regress/regress-786784 while we investigate failures related
to bytecode flushing.
Bug: v8:10560
Change-Id: Ieb5cc7ba87da04133e98c6be25c9a499d79543e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218038
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68046}
Instead of keeping a single {stepping_frame_} per native module, we now
keep one frame id per isolate. Hence, each isolate can step through a
different frame, independent of other isolates.
The on-stack-replacement of the stepping frame already works on a
per-isolate basis, since we only replace the return address of a single
frame, part of the isolate that requested stepping.
The new test (which also executes in a variant with two concurrent
isolates) revealed some more data races to fix.
R=thibaudm@chromium.org
Bug: v8:10359
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I0bb013737162bd09b9f4be9c08990bca7bf736ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214838
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68045}
Make sure that any GCs required for off-thread heap merging happen
before any off-thread handle transferring (both transferring using
OffThreadTransferHandle, and the handles created for the string slot
fixups). This is to avoid the marker from walking Handle roots that
point into off-thread pages which the sweeper doesn't see (and can't
clear mark bits on)
Now, the merging and handle creation is atomic as far as the GC is
concerned. The merging is done before handle creation to avoid the
incremental marker from entering off-thread pages, but we ensure that
the raw objects pointers that point into the off-thread pages (which
are used for creating the main-thread handles) stay valid until the
handle creation completes.
Since handle transfer now happens in the middle of publishing, this
patch also moves the OffThreadTransferHandleStorage ownership over to
OffThreadHeap. This requires some header juggling to avoid leaking
OffThreadTransferHandleStorage into the off-thread-isolate header.
Bug: chromium:1086478, chromium:1011762
Change-Id: Id5e7622d6b5520400a4872c5f6ad396c74b30ca6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218058
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68043}
Since the interpreter is only used for internal testing now, it does not
have an associated frame type any more. We thus cannot call external
functions any more, since a stack walk would not know how to handle
interpreter frames.
All code for calling external (imported) functions is dead by now, so
this CL removes it.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: If4b56b93e63002a1e5463f278f0271eb413762eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218287
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68039}
In BinaryOpAssembler::Generate_BinaryOperationWithFeedback, the
feedback is stored only after the respective builtin/runtime call.
If this call throws an exception, the feedback is lost, leading
to a deopt loop in some cases. This CL fixes that issue by writing
the gathered feedback before passing control to the builtin.
Bug: chromium:1077197, v8:9441
Change-Id: I20e4b14815520224e2c6f8af1af6a89f754ccddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202904
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68038}
This is a reland of 6204768bab
The original issue exposed the problem that NumberEqual performs
implicit conversion of oddballs to numbers, which is incorrect for
abstract equality comparison (i.e. 0 == null must not be true).
This reland fixes this by applying the following steps:
* Introduced a new kNumberOrBoolean value for CompareOperationFeedback,
CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode.
* In CodeStubAssembler::Equal: Further distinguish between boolean and
non-boolean oddballs and set feedback accoringly.
* In JSTypedLowering: Construct [Speculative]NumberEqual operator with
CompareOperationHint::kNumberOrBoolean, when this feedback is present.
JSOperatorBuilder and operator cache are extended accordingly.
* In SimplifiedLowering: Propagate a UseInfo with new
TypeCheckKind::kNumberOrBoolean.
* This leads to the generation of CheckedTaggedToFloat64 in
RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean.
* In EffectControlLinearizer: Handle this new mode. Accept and convert
number and boolean and deopt for rest.
Original change's description:
> [turbofan] Improve equality on NumberOrOddball
>
> This CL cleans up CompareOperationFeedback by replacing it with a
> composable set of flags. The interpreter is changed to collect
> more specific feedback for abstract equality, especially if oddballs
> are involved.
>
> TurboFan is changed to construct SpeculativeNumberEqual operator
> instead of the generic JSEqual in many more cases. This change has
> shown a local speedup of a factor of 3-10, because the specific
> operator is way faster than calling into the generic builtin, but
> it also enables additional optimizations, further improving
> runtime performance.
>
> Bug: v8:5660
> Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67645}
TBR: tebbi@chromium.org
Bug: v8:5660
Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68037}
