Reporting an event requires virtual calls. Frequent incremental events
seem to cause performance regression. Mitigate by batching events
reporting.

See usage in crrev.com/c/2992193

Bug: chromium:1214693
Change-Id: Iff212d0e9f90a2716956458c6e828fbe87a7b780
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992712
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75695}

Since PKU-based switching always switches the permissions for all wasm
code memory in the process, the method should not be on the
{NativeModule} or {WasmCodeAllocator}, but instead on the process-wide
{WasmCodeManager}.

R=jkummerow@chromium.org

Bug: v8:11974
Change-Id: I75a82e51401b2572977c134077e1669cf5077049
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021382
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75694}

This refactors the {GetMemOp} function once again:
Instead of computing (mem_start + (offset_reg + offset_imm)), do compute
((mem_start + offset_imm) + offset_reg). This avoids an overflow in
(offset_reg + offset_imm) when using 32-bit computations, which hides
OOB memory accesses when relying on the trap handler.

As a nice side-effect, this change makes the whole method a lot nicer to
read.

We also need to change {StoreTaggedPointer} now, which was relying on the
inner working of {GetMemOp}. The new version makes the semantics more
transparent at the cost of repeating some logic from (the previous version
of) {GetMemOp}.

R=jkummerow@chromium.org

Bug: v8:11955, chromium:1227465, v8:11951
Change-Id: Ia068ca7c4f7db89b81529edd3438b0e4eee7d23d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015566
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75693}

Low memory notification is historically used by Chromium to request
forced GCs during benchmarking. These should be more aggressive than
the regular GCs and thus we should also discard on such forced GCs.

Bug: chromium:1056170
Change-Id: Ic503e1f440f2b941ae60646b5984fe473bf26410
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021384
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75692}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/70f5848..9c63d2e

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f691b8d..4a3ec12

Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/199485d..f376b41

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/3fa8198..aca9f71

Rolling v8/tools/luci-go: git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86..git_revision:01aa19ce019f7bf94712f3dd2538cf72a2a3451b

Rolling v8/tools/luci-go: git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86..git_revision:01aa19ce019f7bf94712f3dd2538cf72a2a3451b

Rolling v8/tools/luci-go: git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86..git_revision:01aa19ce019f7bf94712f3dd2538cf72a2a3451b

TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I275acfa108759d3b1a37d96d041f5444f50dd435
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3022426Reviewed-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@{#75691}

- Implement f32/f64 fcopysign
- Implement f32/f64 type conversion
- enable some test cases that now pass.

Change-Id: Ia36299484adac885349df25d7c233dd7e43dded4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992914
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75690}

Now that code entries outlive our CodeMap, it's safe to avoid storing
CodeMap metadata after the last active profiler stops. This simplifies
lifecycle logic, and avoids retaining stale data.

Bug: v8:11054
Change-Id: If30fc0835e2033b5bcca204565e05a5cba7823ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000526
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75689}

Port fb28cfe6

Original Commit Message:

    So far, discarded size was maintained by the sweeper but not wired up
    anywere.

    Changes in this patch:
    - Wire up resident size in heap statistics collection.
    - Fix bugs in reporting committed and resident size.
    - Sweeper test: Enforce some internal details. The details should not
      not be checked broadly but be kept as a detail to the sweeper
      itself.
    - Stats collection: Test that committed and resident set size are
      reported and differ after discarding GCs.

R=mlippautz@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: I19be251596ccc955f5c4cd43a46e566001a36ac4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021468Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75688}

lld is part of the main clang package as of
https://chromium-review.googlesource.com/c/chromium/src/+/2977792

Also, this hook has been a no-op since
https://chromium-review.googlesource.com/c/chromium/src/+/2976635

Bug: chromium:1149587
Change-Id: I5663d54dffc65da9bf413bede5ad25412dc33dbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3022041Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75687}

Code event handler relies on having WasmEngine having an isolate, which
happens during Snapshot::Initialize.

Note that this fixes a crash (that the WasmEngine doesn't have an
isolate), but does not get gdbjit integration with Wasm working yet (see
https://crbug.com/v8/11908).

Bug: v8:11967,v8:11930
Change-Id: I56c753d3b66d58e49020688bd387a7c040feb0af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018054Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75686}

Most Torque-defined extern classes already use @generateCppClass. As
Nico pointed out in [1], it would be nice to convert the remaining
classes and remove this option. This change converts about a third of
those remaining classes. I know that the future of Torque-defined
classes is a subject of some debate right now, but I think that it's
worth doing a few mechanical changes to reduce the existing variety of
options.

[1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#

Bug: v8:8952
Change-Id: Ic96f9b16397149099f87380f68e01b1f2a6d5b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018056Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75685}

So far, discarded size was maintained by the sweeper but not wired up
anywere.

Changes in this patch:
- Wire up resident size in heap statistics collection.
- Fix bugs in reporting committed and resident size.
- Sweeper test: Enforce some internal details. The details should not
  not be checked broadly but be kept as a detail to the sweeper
  itself.
- Stats collection: Test that committed and resident set size are
  reported and differ after discarding GCs.

Bug: chromium:1056170
Change-Id: Icf8871c7ea3b28253233485c736b2ca4816fd6f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020971Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75684}

Monotonicity of typing of arithmetic operations could fail in the
presence of optimized_out Oddball inputs, which can arise in dead code
in resumable functions. The CL fixes these with a small change to
BinaryNumberOpTyper.

Bug: chromium:1227677
Change-Id: I1e1d2e174b757e839d776685f52f7c4ac900844b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020972Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75683}

Bug: chromium:1224142
Change-Id: I42ed4ad23057837972cdbebb10e861948da9ddb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017813
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75682}

These need some consideration.  Clang apparently considers V8_UNLIKELY
to mean "always false", which seems questionable to me (possibly a
bug?).  That said, removing it in the cases here doesn't seem likely to
cause problems -- the logging instance seems fine, and the other used to
not have the macro and gained it in a commit that seemed to have nothing
to do with performance.

The trampoline register change is safe, but perhaps V8 will support an
architecture in the future which needs this conditional?

I'd leave these as-is, but it also seems a shame not to enable
-Wunreachable-code-aggressive just because of these...

Bug: chromium:1066980
Change-Id: Ib819298cecba082666c26fa7010009f8e9441bf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994805
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75681}

When porting to MacOS (in https://crrev.com/c/1282960), we forgot to
update signal masking to unmask SIGBUS instead of SIGSEGV.

R=mseaborn@chromium.org, ahaas@chromium.org

Bug: chromium:906565
Change-Id: I486a204f33139f1da4a074a07878921692b713e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015565
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75680}

This reverts commit ea55438a.

Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview

Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}

Bug: v8:11947
Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75679}

A single ClusterFuzz report flushed out two minor issues in the
bit fiddling routines.

Bug: chromium:1227752,v8:11515
Change-Id: I16ab914b7c3859f55aa141ced371dd80171d0cb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017809Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75678}

Add discarded of memory on memory reducing garbage collections. In
addition, add tracking of discarded memory and properly adjust the
resident memory of heap dumps.

- Memory is discarded during sweeping and the counter is persistent
  across garbage collection cycles.
- Subsequent sweep calls are not supposed to touch the memory anymore.
- As a simplification, discarded memory is tracked on page granularity
  and assumed to be fully paged in as soon as a page's free list entries
  are reused for allocation.

Change-Id: Icfd58f49f3400c4df0d482e20326a0c43c1ca9f5
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015563
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75677}

The recently added experimental support for non-nullable locals
(https://chromium-review.googlesource.com/c/v8/v8/+/3010283) made
DecodeLocalGet slightly bigger, which caused Clang not to inline
it any more, which has a measurable performance impact because this
is one of the hottest decoding functions. Forcibly inlining it
fixes the regression.

Bug: chromium:1227332
Change-Id: Ifb85f7f5a43ad1c0376bbf37e4af84fb4903371f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018206Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75676}

- Enumerates the flags currently noy supported.
- Enables pointer compression.

No-Try: true
Bug: v8:11234
Change-Id: I030ca5a18a2ccf1e3484b2c69d5c1b1c91579c7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015571
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75675}

Currently with sparkplug we don't flush bytecode / baseline code of
functions that were tiered up to sparkplug. This CL adds the support to
flush baseline code / bytecode of functions that have baseline code too.
This CL:
1. Updates the BodyDescriptor of JSFunction to treat the Code field of
JSFunction as a custom weak pointer where the code is treated as weak if
the bytecode corresponding to this function is old.
2. Updates GC to handle the functions that had a weak code object during
the atomic phase of GC.
3. Updates the check for old bytecode to also consider when there is
baseline code on the function.

This CL doesn't change any heuristics for flushing. The baseline code
will be flushed at the same time as bytecode.

Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
Bug: v8:11947
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75674}

Instantiation was inside a DCHECK and therefore did not happen in
non-debug modes. Turn the DCHECK into a CHECK.

R=clemensb@chromium.org

Bug: chromium:1227685
Change-Id: I13240109326a2c94576f6651963543187d96ad3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017806Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75673}

This CL makes `AllocateUninitializedJSArrayWithElements` always perform
inline allocation, regardless of the `v8_allocation_folding` flag.

Since there are other hand crafted folded-allocations in v8 (e.g. json
parser), it is hard to catch and fix them all, including this one. Also
this function will trigger an IR compilation error at the moment with
`V8_ALLOCATION_FOLDING_BOOL = true`.
So it's better to revert it instead of fixing the compilation error
and make the code more complex.

PS: The `inline_allocation` check was introduced by https://chromium-review.googlesource.com/c/v8/v8/+/2946667.

Change-Id: Ia88dcc23bec47a7aefb3315dd73f6d80452053b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017695Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Cr-Commit-Position: refs/heads/master@{#75672}

Port [wasm][liftoff][ia32][x64] Detect SIMD NaNs for fuzzing

Change-Id: I166ee58ad1fe682847ee252db134ab615056b416
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020545Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Commit-Queue: Ji Qiu <qiuji@iscas.ac.cn>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75671}

Fixes bazel bot, broken by
https://chromium-review.googlesource.com/c/v8/v8/+/2987599

No-Try: true
Change-Id: I66c8eb4f014e0a8e0bec2186a1fa54192eaff7e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017810
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75670}

Enforcing this invariant allows for assuming that free memory is left
untouched.

Bug: chromium:1056170
Change-Id: Ia225a31bbe6d394b8310ce512ed4f76f78e5c177
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017808
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75669}

Bug: chromium:1066980
Change-Id: I189e208e9d089967bfa1b4f27ffdda49938a1f5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3019184
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75668}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/857a0f2..70f5848

TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: Ib38adcb3001d4176cb0b3cd8fb4e0cc54511c910
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020064Reviewed-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@{#75667}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1ed240a..857a0f2

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/71adf4f..f691b8d

TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I845b57622cbadbc3804a142b29f33885a2abaefe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3019012Reviewed-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@{#75666}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9d1af1f..1ed240a

Rolling v8/third_party/aemu-linux-x64: czR22wy3jcAfrw7l4ljto3qX6BpD2DSahnluWvqUockC..QunhZeUueNJF63FP9uXIb-TVJNazpdKD5TQAi_D7ZLEC

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e397699..71adf4f

Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/1ea7a15..1889684

Rolling v8/third_party/logdog/logdog: https://chromium.googlesource.com/infra/luci/luci-py/client/libs/logdog/+log/9a84af8..794d09a

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/d0c5792..3fa8198

Rolling v8/tools/luci-go: git_revision:6808332cfd84a07aeefa906674273fc762510c8c..git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86

Rolling v8/tools/luci-go: git_revision:6808332cfd84a07aeefa906674273fc762510c8c..git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86

Rolling v8/tools/luci-go: git_revision:6808332cfd84a07aeefa906674273fc762510c8c..git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86

TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I714e9cde0aab93bd7d762a9e56cefcd1320e9711
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017145Reviewed-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@{#75665}

This CL implements the resolution of function overloads based on
run-time checks of the type of arguments passed to the JS function.
For the moment, the only supported overload resolution is between
JSArrays and TypedArrays.

Bug: v8:11739
Change-Id: Iabb79149f021037470a3adf071d1cccb6f00acd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2987599Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75664}

The Schönhage-Strassen method for *very* large inputs.

This is a reland of 347ba357,
with added zero-initialization to pacify MSan (spurious report).

Originally:
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000742
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75659}

Bug: v8:11515
Change-Id: Ieac6e174bde6eb09af0a9a9a49969feabca79e81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018081Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75663}

I noticed a case where Torque can generate an invalid .inc file, and I
think that it's worth adding a check that can emit an error during
run_torque rather than letting the developer hit a C++ compilation
failure later.

Example error message, if you add @export to StrongDescriptorArray:

Torque Error: Exported class StrongDescriptorArray cannot be in the same
              file as its parent extern class DescriptorArray

Bug: v8:7793
Change-Id: Ia69124a4177bd7a53f95442249fae88cb16e354a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015655Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75662}

Includes:
- https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/3014475
- https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/3006580

Bug: chromium:1187004, chromium:1187003, chromium:1187006, chromium:1187007
Change-Id: I6afbeb13d6c1f61a9fd7c890068f173b47beb252
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013351Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75661}

This reverts commit 347ba357.

Reason for revert: MSAN https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/39275/overview

Original change's description:
> [bigint] FFT-based multiplication
>
> The Schönhage-Strassen method for *very* large inputs.
>
> Bug: v8:11515
> Change-Id: Ie8613f54928c9d3f6ff24e3102bc809de9f4496e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000742
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75659}

Bug: v8:11515
Change-Id: Ib0601e91bbd8ac5732b57730e3507eb0fa7e3947
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015574
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75660}

The Schönhage-Strassen method for *very* large inputs.

Bug: v8:11515
Change-Id: Ie8613f54928c9d3f6ff24e3102bc809de9f4496e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000742
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75659}

Reset the instance before the test run, to ensure it runs with the
same initial state as the reference run.

R=clemensb@chromium.org

Bug: chromium:1227591
Change-Id: Ie78b4b84e3df37ab8955c240f1d41e2f5e89a5de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015572Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75658}

We cannot emit the constant pool within the safepoint table data. It
seems like we also don't do that, but the forgotten
{BlockConstPoolScope} triggered a DCHECK.

R=leszeks@chromium.org

Bug: chromium:1227351, chromium:1217074
Change-Id: I187004c83e05002c651a15643bddea5b02cb00c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015559Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75657}

To get there, also:

- Refactor AllocationSite serialization as necessary.

- Make some accessors on AllocationSite atomic.

- Add JSObjectRef::raw_properties_or_hash().

- Eliminate use of IsFastLiteral in JSCallReducer. It isn't really
  needed there and we want to have only a single piece of code
  traversing boilerplates. (We still have a separate traversal in the
  serializer but that will be removed soon.)

- Merge IsFastLiteral checks into JSCreateLowering's
  TryAllocateFastLiteral.
  Note: TryAllocateFastLiteral doesn't explicitly look at the
  boilerplate's elements kind beyond bailing out for
  DICTIONARY_ELEMENTS in the beginning. After that it looks only at
  the backing store instance type. There is no room for confusion
  because, while elements kind transitions can generally happen
  concurrently to TryAllocateFastLiteral, boilerplates can never
  transition to DICTIONARY_ELEMENTS (added a CHECK for that).

- Slightly adapt CompilationDependencies and remove obsolete comments.

- Fix JSHeapBroker::ClearReconstructibleData (clearing of Refs in
  stress mode) to exclude JSObjectRefs with extra data.

Bug: v8:7790
Change-Id: Iee1232d01e04bcd00db04d48f6e82064fce6ff62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008894
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75656}