Adds check for
- same heap on assignment
- header and containment

The verification state is eagerly created for on-heap Member
references using caged heap and lazily created on first assignment for
all others.

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

This is a reland of 6c65e858

Changes since revert:

- Add --disable-shared-ro-heap-for-testing flag that is implied by
  d8's --stress-snapshot, since RO heap sharing currently
  does not support deserializing/serializing while original Isolate
  is still running
- Add BUILD.gn assert that v8_enable_pointer_compression_shared_cage
  requires x64 or arm64

Original change's description:
> [ptr-cage] Turn on shared pointer cage by default for arm64 and x64
>
> Bug: v8:11460
> Change-Id: I9ab419b5e90fbe677e1d63b41699d90552839e98
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873226
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74422}

Bug: v8:11460
Change-Id: I7eb189b7f8ac3e30da96b0dadd2c085f08a1a0b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74448}

Bug: v8:11460
Change-Id: Ie79e223f2ba49c9df816464760b0a8e5397e2841
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876072
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74447}

The function will be used to implement the web memory measurement API.

This adds an |allocated_bytes_at_last_gc| counter to each normal page.
The counter is updated by the sweeper.

Bug: chromium:1181269
Change-Id: If6612de06f373a839fce986c71ba3dfde4d9c9c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880534
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74446}

The ScheduleEarly phase of the scheduler initializes the minimum_block
values which are only required for loop hoisting. If there are no loops,
running this step is unecessary overhead.

BUG=v8:9684

Change-Id: Iba181fd55ecd634c05d3f8eb4282bd0be3141c21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880538Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74445}

cpplint rules change over time, and we change the exact rules we enable
for v8. This CL removes NOLINT annotations which are not needed
according to the currently enabled rules.

R=ahaas@chromium.org

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

This is the 1st CL in a series of CLs with the goal to significantly
reduce the number of includes in torque-generated files to reduce
the build time of Torque's output.

So far, all torque-generated builtins included all (197) other builtins
generated by Torque. This CL adds tracking of definition locations to
Torque's ImplementationVisitor that enables it to only include those
builtins that are actually needed for compilation. This change reduces
the number of includes for the majority of builtins by 150-180 files.

Bug: v8:11528

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

It was using MakeRef but it's not guaranteed that we can create a Ref
for the prototype if we haven't seen it during serialization. Use
TryMakeRef instead.

Tbr: jgruber@chromium.org
Bug: chromium:1206670, v8:7790
Change-Id: Ifc00cb1dbf7747c766011f5915bb15fe093b920c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878749Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74442}

This reland patch:
https://chromium-review.googlesource.com/c/v8/v8/+/2867473
(See patchset 1)

The problem was blink injecting interceptor into the window object. It
observes "observation" and "mutations" on this object. When it happens
to the initial empty document, the IPC DidAccessInitialDocument() is
sent and modify the state of the browser process. Causing two tests to
fail.

The diff (See patchset 1..2) includes:
1. Use JSObject::HasRealNamedProperty instead of JsObject::HasProperty.
   This skips the interceptor and do not walk the prototype chain.
2. Invert JSObject::HasRealNamedProperty() with
   IsSharedArrayBufferConstructorEnabled(), just in case. This avoid
   observing the object when not needed.

Original patch description:
---
This change makes it possible to enable SharedArrayBuffer per Context,
controlling whether it should be enabled or not with a callback. The
previous implementation of the reverse origin trial for
SharedArrayBuffer was broken, since the feature could only be enabled
globally per process, and only if the feature flag is set early enough
in the v8 initialization. This does not play well with how origin
trials work.

The implementation is similar to the callbacks that already exist for
the origin trials for WebAssembly simd and exceptions.

SharedArrayBuffer is still controlled by the flag
harmony_sharedarraybuffer. If that flag is disabled, then
SharedArrayBuffer is disabled unconditionally. On top of that, this CL
introduces a new flag for enabling SharedArrayBuffer per context. If
that flag is set, a callback is used to determine whether
SharedArrayBuffer should be enabled.

Note that this only controls whether the SharedArrayBuffer constructor
should be exposed on the global object or not. It is always possible
to construct a SharedArrayBuffer using

  new WebAssembly.Memory({
    shared:true, initial:0, maximum:0 }).buffer.constructor;

There are few things which I do not like of this approach, but I did
not have better ideas:

1. The complex logic of dobule flag + callback. However, this seemed
the best way to me to not break embedders which rely on that flag
being enabled by default.

2. The fact that what actually matters is just whether the callback
returns `true` once. It would be good to check that the callback gives
a consistent return value, or to provide a better API that cannot be
missunderstood.

Bug: chromium:923807,chromium:1071424,chromium:1138860
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867473Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74378}

---

Bug: chromium:923807,chromium:1071424,chromium:1138860,chromium:1206187
Change-Id: Ibc6b4f8c0e0827178b7f0cbe4b942444bbbe6216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880215Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74441}

Hopefully making it easier to determine the problem when a
dynamically-sized object type allows too small sizes.

Change-Id: Iac33c501da6349e02f570fe8c9092758cd9d59a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874654
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74440}

Using xxbrq we can reverse the order of indices in a
single instruction.

xxbrq is also implemented in the simulator in this CL.

Change-Id: I4744cefeec0a4e07b41fcb0d35de08ad42e55883
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878573Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74439}

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

Our current logic for the console API's monitor implementation relies on
JavaScript's arguments array. In arrow functions, this results in an
error, resulting missing print statements from monitor.

This CL at least re-enables the print statements, but does not print the
arguments in the case of arrow functions.

Change-Id: Ibf6c2a0fb5e0cc911c257520a59a875992fe3777
Bug: chromium:1206137
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880216Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74437}

Structs with zero fields weren't handled correctly, because the GC
has a requirement that each object occupies at least two pointers.

On the high end, Wasm structs accidentally had a limit of 255 pointers
including object header. This CL bumps that to the intended limit
of 999 fields (which is arbitrary and could be raised if needed).

Bug: v8:7748
Change-Id: I13a3f45b3ddb28023c76775da32be0d07ec2ffd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874653
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74436}

To enforce W^X for the WebAssembly code space, we want to explore using
Intel memory protection keys for userspace, also known as MPK, PKEYs, or
PKU. Instead of flipping page protection flags with mprotect (which
incurs a high syscall overhead; and which switches flags for the whole
process), with PKU we associate a key with each page once and then
change the permissions of that key with a fast thread-local register
write. That is, this gives both finger-grained permissions (per-thread)
and more performance.

This CL is starts experimenting with PKUs by
(1) adding a flag to turn on prototype PKU support; and if set to true
(2) allocates a protection key once per {WasmCodeManager} in x64 Linux
systems.

This is a partial reland of https://crrev.com/c/2850932, which was
reverted due to an added histogram failing Chromium integration.
Since the histogram (to record PKU support) is independent of the
functionality in this CL, we split it out into its own CL (to come).

R=clemensb@chromium.org
CC=​jkummerow@chromium.org

Bug: v8:11714
Change-Id: I67c8679495c55fa51da8243582963649abde660b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878738
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74435}

Bug: chromium:728583
Change-Id: Ie7a46ff884ae9474d342c50e5c6cdcf5c0c0e46a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874397Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74434}

This is a reland of b271648e

Unfortunately the test can still throw a fatal error, since there are
other possible paths for OOM.

Original change's description:
> [runtime] Add length check in ConvertElementsWithCapacity
>
> This also propagates the exception through all the users of
> ConvertElementsWithCapacity.
>
> Bug: chromium:1201626
> Change-Id: Ie44ba4327a4c3a20f1376477f45d3cd95d0da3b3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857961
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74412}

Bug: chromium:1201626
Change-Id: I164ca1aca21ad6f45ccf8893fb07a47cd5ed079a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2877833Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74433}

'override' implies 'virtual', thus 'virtual' should be skipped.

R=mlippautz@chromium.org

Bug: v8:11717
Change-Id: If5e9c2aeec85fcf0832f9712b6e09752c4d2c2d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878737Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74432}

The application may itself change ASAN poisoning which conflicts with
the memset() right before poisoning memory.

This is relevant for destructors but also when invoking Resize() on an
object that uses ASAN container annotations. Annotations are hard to
adjust for the embedder as it is not clear upfront whether the call will
succeed.

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

The DCHECK seems to fail with MSVC on x86 builds. This CL disables this
DCHECK when map packing isn't enabled until we have a proper fix.

Bug: v8:11748, v8:11624
Change-Id: Iec98d161c5cd2b6a910c29287b54c8e3de017e83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878735Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74430}

This CL changes the accounting of array buffers, such that Detach
deducts the backing store immediately. Previously this was corrected
in the next GC cycle.

Not updating backing_store_bytes_ immediately could cause an overflow
in WasmMemoryObject::Grow. Grow first detaches the backing store from
the old JSArrayBuffer and then attaches it to a new one. This results
in the backing store being accounted twice temporarily, this could cause
overflows on 32-bit systems.

Bug: chromium:1204455
Change-Id: I7cf2ca9a12bb5caf7bcffa25a34567774cf155b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871458
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74429}

This API is the new public one added in ICU 69.1
in https://github.com/unicode-org/icu/pull/1610

Bug: v8:11512
Change-Id: I424e15e6a60edee7c98e6ce55974986f0bb6ab1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876368
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74428}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a5d4757..c844180

Rolling v8/buildtools/linux64: git_revision:6771ce569fb4803dad7a427aa2e2c23e960b917e..git_revision:dfd036f3be5422c7b61cf16369bde28b3a8cccc8

Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/5844fc6..d6f21e0

Rolling v8/third_party/aemu-linux-x64: QpXtlWg0Hrksvqhm2JkK5cg7xWznHgNj3aHSgOF-cCkC..IFKk3HKRVi_NvWa_9abMZahaAGY7hGQ0MzuloLf6TkgC

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5185110..c92267a

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/5009fd6..e77e3c8

Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/d0c227c..a2e8a8a

TBR=v8-waterfall-sheriff@grotations.appspotmail.com

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

gcc complains about the 'extern "C"' going after attributes.

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

This reverts commit 6c65e858.

Reason for revert: V8 Linux64 fyi bots are red https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20fyi/21963/overview

Original change's description:
> [ptr-cage] Turn on shared pointer cage by default for arm64 and x64
>
> Bug: v8:11460
> Change-Id: I9ab419b5e90fbe677e1d63b41699d90552839e98
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873226
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74422}

Bug: v8:11460
Change-Id: Ia97838cdce5073cbdb8eaa3aa819aa92c2a081dd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878854
Auto-Submit: Zhi An Ng <zhin@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@{#74425}

Tbr: mslekova@chromium.org
Bug: v8:11745
Change-Id: Ib29745f9926810a4b1a18c8b779e62e1d9f69f2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2877863Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74424}

HeapNumberRef can be serialized in the background, so long as we record
a dependency to check at the end of compilation to ensure that the
number (interpreted as bits) has not changed.

Bug: v8:7790
Change-Id: I5c1c27466192580ff33bd55c8fa44dac957f2171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2872827
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74423}

Bug: v8:11460
Change-Id: I9ab419b5e90fbe677e1d63b41699d90552839e98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873226
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74422}

Change-Id: I3cda4c4ac03a56191e4c034aef34879c23da993d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876449Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74421}

Port 05265d88

Original Commit Message:

    This removes all wasm-related flags in no-wasm builds.
    We could have made them read-only, but fully removing them actually
    forces us to consider the no-wasm case at every use site, which often
    hints at further cleanups.

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

Change-Id: I2340276a05a9a67756d128501e1e88a77c56effe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876451Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74420}

The test reads slack properties after the end of the object. With
FLAG_stress_concurrent_allocation a background thread allocates a lot
of objects and might cause concurrent sweeping which causes a TSAN
race. Since this only happens with this test, disable the test in this
configuration.

Bug: v8:11698
Change-Id: If922a4a233006d3719294ae2f3a05820117e9250
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856536Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74419}

Destroyed large pages can be reallocated before the OS get a chance to
reclaim and clear them. In such cases we will get non-zero memory in a
newly allocated page.
Normal pages are not affected since they are kept in page pools instead
of being freed.
Fix by explicitly clearing the payload when destroying a large page.

Bug: chromium:1056170, chromium:1206274
Change-Id: I6436302f50b8f0b4ef41288425bf464b0eb52d5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874404
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74418}

It turns out that KeyAccumulator::GetKeys will fail if the object it is
operating on is a Proxy with an ownKeys() or getOwnPropertyDescriptor()
trap that throws. Handle this case in
Isolate::GetImportAssertionsFromArgument by bailing out early.

Bug: v8:11730
Change-Id: I363bf2d218f6ba7eeb2001cd644f5529901fdb3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2875541Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74417}

The change broke msvc build. This CL fixes it.

Original change description:
> This reverts commit 97b4ed74.
>
> Microsoft x86_64 ABI considers XMM6-XMM15 as non-volatile
> (callee-saved), which means that the compiler can store pointers in them.
> We need to make sure they are pushed onto the stack inside the stack
> scanning trampolines.

> Bug: v8:11710
> Change-Id: Ida804fe49d3d3b6f179ec276903a42ec8d3d86be
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865745
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Auto-Submit: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74376}

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

The heap sandbox mode was broken after the introduction of
WasmExportedFunctionData objects due to missing external pointer
handling. This CL implements that.

Bug: v8:10391
Change-Id: Icc6a2944b68f475c40b6431ab26400c35083b7bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2862771Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#74415}

This reverts commit b271648e.

Reason for revert: New test fails: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/42282/overview

Original change's description:
> [runtime] Add length check in ConvertElementsWithCapacity
>
> This also propagates the exception through all the users of
> ConvertElementsWithCapacity.
>
> Bug: chromium:1201626
> Change-Id: Ie44ba4327a4c3a20f1376477f45d3cd95d0da3b3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857961
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74412}

Bug: chromium:1201626
Change-Id: I764256e9d0dcc69ea3a2f3c77afaca73a910bb66
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876861
Auto-Submit: Clemens Backes <clemensb@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@{#74414}

When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer:
	receiver.apply(this, args) ->
	this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target
is not a heapconstant.

With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%.

function reduceArray(func, arr, r) {
    for (var i = 0, len = arr.length; i < len; i++) {
            r = func.apply(null, r, arr[i]);
    }
    return r;
}

var a = 0; for (var i = 0; i < 10000000; i++) {
    a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1);
}
console.log(a);

This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls.

Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74413}

This also propagates the exception through all the users of
ConvertElementsWithCapacity.

Bug: chromium:1201626
Change-Id: Ie44ba4327a4c3a20f1376477f45d3cd95d0da3b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857961
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74412}

Port dc7906c9

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

Change-Id: Ic6643492969efcf4113a25a886792038b291cacf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876987Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74411}

Within the inspector we should be consistent about passing the script ID
always as integer, and only convert to String16 when actually needed.
That (a) saves memory (and some runtime overhead) when stashing away
call frames, for example in case of async stack traces, and (b) reduces
confusion which representation to chose.

Bug: chromium:1162229
Change-Id: I9591931da0a307779372f36aba6e155ec22bbe3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876856
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74410}