See: https://github.com/nodejs/node/pull/32831
Change-Id: I1e537bf9378156e8c309dbf4e2532257c98ec151
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191056Reviewed-by: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#67817}

The bool specialization of DataRange::get was removed recently as it is
not used anymore. Add a static assert to ensure that we do not run into
the undefined behavior that this specialization was meant to prevent.

R=clemensb@chromium.org

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

Load extends always load 64-bits. Previously, we were setting the max
alignment to be the size_log_2 of the load_type. For LoadExtends the
load_type indicates what the lane size to be extended is, *NOT* the size
to be loaded.

Bug: chromium:1082848
Change-Id: I0c4115ea6ec916211b03afdb83376ccc05c0c244
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202721Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67815}

This only changes iterator type specifiers and cast expressions.

See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html
for more on this warning.

Bug: v8:10488
Change-Id: I1e6747aafb24fd2d9d946e054fb20fbd1d8e5b26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191921Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67814}

This only changes iterator type specifiers and cast expressions.

See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html
for more on this warning.

Bug: v8:10488
Change-Id: I26b4f837524c640021e44f39315201173b5867f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191348Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67813}

The scheduler could schedule unreachable nodes on two basic blocks that
later merge. Update DCHECK in graph-assembler's basic block updater to
only check for the self-containedness of unreachable basic blocks
removed from the schedule after all the blocks have been re-written to
allow for this case.

BUG=chromium:1079446,v8:9684

Change-Id: I91899dbf389e4425542dbd2b1ca95c3f6ad79c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196354Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67812}

Splits out all of PagedSpace and subclasses into paged-spaces.h. Also
moves CodeObjectRegistry to code-object-registry.h.

Bug: v8:10473, v8:10506
Change-Id: I35fab1e545e958eb32f3e39a5e2ce8fb087c2a53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201763Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67811}

Port 99a361ee

Original Commit Message:

    Implementation for x64 and ia32.

R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I2b199a71178a3ebbe488d438b997014303a82d08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202717Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67810}

Experimenting with incrementing live_byte_count_ using a relaxed CAS
operation. If no regression is found, we could get away with background
threads increasing that counter directly, instead of using separate
counters like concurrent markers.

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

Implementation for x64 and ia32.

Bug: v8:9909
Change-Id: Id494d292fe8ab464e07f4b9520d1c251d355615a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198456
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67808}

The --no-wasm-async-compilation disabled async compilation so far, but
async compilation was still possible over streaming compilation. With
this CL, also streaming compilation is disabled.

R=clemensb@chromium.org

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

Bug: v8:9909
Change-Id: Ia87c46a45804dc0a3b5e7275a92c263fbcd4b145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2197547
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67806}

The devtools frontend used this to set a lower interval (100us). Now the
frontend will stop setting this category and we will always profile
with 100us (which was already the default).

Bug: chromium:1082220

Change-Id: Iaa671d9750ad4c13b95c2c1ba1e433a1077c858a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198989Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67805}

R=ahaas@chromium.org

Change-Id: I757abd5d0e8e63745482e9bec66abf39a174f0ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201759Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67804}

This reverts commit 580917d2.

Reason for revert: fix in patchset 2

Original change's description:
> Revert "cppgc: Stack scanning using ObjectStartBitmap"
> 
> This reverts commit d3a72e3c.
> 
> Reason for revert: MSAN failures (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/32360)
> 
> Original change's description:
> > cppgc: Stack scanning using ObjectStartBitmap
> > 
> > This CL implements stack scanning for cppgc.
> > Given a value on the stack, the MarkingVisitor uses
> > PageBackend::Lookup to checks whether that address is on
> > the heap. If it is, BasePage::TryObjectHeaderFromInnerAddress
> > (introduced in this CL) is used to get the relevant object
> > header. Note that random addresses on the heap might point to
> > free memory, object-start-bitmap, etc.
> > 
> > If a valid object header is found:
> > * If the object is not in construction, the GCInfoIndex is used
> > the get the relevant Trace method and the object is traced.
> > * Otherwise, the object is conservatively scanned - i.e. the
> > payload of the object is iterated word by word and each word is
> > treated as a possible pointer.
> > 
> > Only addresses pointing to the payload on non-free objects are
> > traced.
> > 
> > BasePage::TryObjectHeaderFromInnerAddress assumes on LAB on the
> > relevant space, thus all LABs are reset before scanning the stack.
> > 
> > Bug: chromium:1056170
> > Change-Id: I172850f6f1bbb6f0efca8e44ad8fdfe222977b9f
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190426
> > Commit-Queue: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67795}
> 
> TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
> 
> Change-Id: I3caef6f9f55911fd1a86e895c3495d1b98b1eac2
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201136
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67796}

TBR=ulan@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,bikineev@chromium.org,omerkatz@chromium.org

# Not skipping CQ checks because this is a reland.

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

Avoid the SFI lookup in the script's weak SFI list, which could fail if
the function was somehow GCed between allocation and finalization, and
instead hold a Handle to each finalizing SFI in the finalization data
structure.

For similar reasons, also check that the compiled function to have its
compilation finalized is still compiled by that point, because it could
have been bytecode flushed.

Bug: chromium:1081691
Change-Id: I4e1f681263473a966e782b23291636d10a9209c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199349
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67802}

The existing non-builtin implementation is returning wrong results.
For example, given the value 63 as a uint8_t it returns 38 (should be 6).

The new implementation follows the naive algorithm presented in figure 5-1
in Hacker's Delight section 5-1.
Note that the algorithm in the book is designed for 32 bit numbers, so we
extended it to support 64 bit as well.

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

When reducing api calls, TurboFan infers the maps of the receiver
and tries to drop the compatibile receiver checks if we can verify that
it is safe to do so. One of these checks involves checking that the holder
is same across all of the receiver maps. However, when receiver itself
is the holder the existing checks prevent TurboFan from optimizing the
api calls.

Change-Id: I6aad39a1a9bb351550e04dd883fa49d7d53ca691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201076Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67800}

Add a new OffThreadObjectDeserializer, which can deserialize a snapshot
into an OffThreadIsolate.

This involves templating the Deserializer base class on Isolate, and
amending OffThreadHeap to be able to create Reservations same as the
main-thread Heap can. Various off-thread incompatible methods are
stubbed out as UNREACHABLE in OffThreadIsolate overloads.

There is currently no API entry into the off-thread deserialization, but
under --stress-background-compile it now runs the CodeDeserializer (i.e.
code cache deserialization) in a background thread.

Bug: chromium:1075999

Change-Id: I2453f51ae31df4d4b6aa94b0804a9d6d3a03781e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172741
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67799}

We can use existing macros to define this getter/setter rather than hand
writing it -- as a side effect this ends up defining an Isolate overload
of the getter which was otherwise missing.

Bug: v8:10506
Change-Id: I0bc5a3082b5ed0416c8099a94e7d2e32a2bd363f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199350
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67798}

It was enabled accidentally.

Bug: chromium:1082426
Change-Id: I08019aeb3ddc34fea8ce9e08c6ace3a95335c171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199354
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67797}

This reverts commit d3a72e3c.

Reason for revert: MSAN failures (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/32360)

Original change's description:
> cppgc: Stack scanning using ObjectStartBitmap
> 
> This CL implements stack scanning for cppgc.
> Given a value on the stack, the MarkingVisitor uses
> PageBackend::Lookup to checks whether that address is on
> the heap. If it is, BasePage::TryObjectHeaderFromInnerAddress
> (introduced in this CL) is used to get the relevant object
> header. Note that random addresses on the heap might point to
> free memory, object-start-bitmap, etc.
> 
> If a valid object header is found:
> * If the object is not in construction, the GCInfoIndex is used
> the get the relevant Trace method and the object is traced.
> * Otherwise, the object is conservatively scanned - i.e. the
> payload of the object is iterated word by word and each word is
> treated as a possible pointer.
> 
> Only addresses pointing to the payload on non-free objects are
> traced.
> 
> BasePage::TryObjectHeaderFromInnerAddress assumes on LAB on the
> relevant space, thus all LABs are reset before scanning the stack.
> 
> Bug: chromium:1056170
> Change-Id: I172850f6f1bbb6f0efca8e44ad8fdfe222977b9f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190426
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67795}

TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org

Change-Id: I3caef6f9f55911fd1a86e895c3495d1b98b1eac2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201136Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67796}

This CL implements stack scanning for cppgc.
Given a value on the stack, the MarkingVisitor uses
PageBackend::Lookup to checks whether that address is on
the heap. If it is, BasePage::TryObjectHeaderFromInnerAddress
(introduced in this CL) is used to get the relevant object
header. Note that random addresses on the heap might point to
free memory, object-start-bitmap, etc.

If a valid object header is found:
* If the object is not in construction, the GCInfoIndex is used
the get the relevant Trace method and the object is traced.
* Otherwise, the object is conservatively scanned - i.e. the
payload of the object is iterated word by word and each word is
treated as a possible pointer.

Only addresses pointing to the payload on non-free objects are
traced.

BasePage::TryObjectHeaderFromInnerAddress assumes on LAB on the
relevant space, thus all LABs are reset before scanning the stack.

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

Basically, remove 'Turbolizer is currently migrating to TypeScript.'

Bug: v8:7327
Change-Id: I83df1b4cf568e17c2e9393865702e5bb722a8b95
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199353Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67794}

This commit resolves compilation errors on SmartOS that
were found while upgrading Node.js.

See: https://github.com/nodejs/node/pull/32831
Change-Id: Ia2a2e028ba4f5bfd69c050cab4fb4e13af5eefd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191054Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67793}

Also adds missing header includes.

Bug: v8:10473
Change-Id: Ib5bf599dae5bc954edcb6e6fcbd83004bd48c1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199347
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67792}

Bug: chromium:1082309, chromium:1082083
Change-Id: I616da287adce5db7952eadf11364a7593e405fdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199346Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67791}

R=ahaas@chromium.org

Bug: v8:10408
Change-Id: Ic5cb2b915584c64656bfc5baf8c9524a7d5bf48c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196346Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67790}

There should be a space between the quantity and the unit symbol
as per the SI, so this commit fixes this issue.

Change-Id: I3356942391d96906f3e3840c7bb802e10f29eb4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190230
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67789}

This is needed to trace objects found durinbg stack scanning.

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

Bug: v8:10501
Change-Id: I6dad0f4da4d7c50d0793d39a5a119defb6b53844
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191392
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67787}

The AVX implementation does not have dst == input(0), so the vminps call
was wrong. The intention is to compare the 2 input operands.

Bug: chromium:1081030
Change-Id: Id54074327a6aca4b75988fc9d85beccfeabfc791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194471Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67786}

- Rewrites the following builtins using Torque:
  WasmAtomicNotify
  WasmI32AtomicWait64
  WasmI64AtomicWait64
  WasmAllocateStruct
- Adds some helper builtins to reduce the size of the Atomics builtins.
  These do multiple conversions and CSA inlines all of this code. As
  these are runtime calls, the call overhead should be negligible.
  WasmInt32ToNumber
  WasmUint32ToNumber

Change-Id: Ie15e15a965dc383c54ae50164d83bce211178888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2176895Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67785}

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

... when one of the receivers is a JSArray that may have a read-only
length.

Bug: chromium:1069530
Change-Id: Idbaf1a9030bb5a0f9c25e30925f18f603a99832f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196353Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67783}

Port 91cbf3e3
https://crrev.com/c/2171475

Change-Id: I09e24f7da0449fa891633794bc3a8ef639352eeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198862Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#67782}

Port b931af5d
https://crrev.com/c/2190423

Change-Id: I9d5eeae078604e1bd5241afea14f169f45711ce3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198056Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#67781}

Port 91cbf3e3

R=zhiguo.zhou@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Ie69563747b10a2a783289d21b39ea3c48e99e2c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198361Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67780}

This CL fixes a bug in Liftoff where stack parameters for builtins were
pushed in the reversed order.

CC=bbudge@chromium.org
R=clemensb@chromium.org

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

We can't attach a meaningful stack trace to the AggregateError
Promise.any rejects with, but we can augment the individual errors'
stack traces with Promise.any and the index of the corresponding
Promise in the input.

Bug: v8:9808
Change-Id: I7ba754c9b043594decaac8b3a23be74f05c3dffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198983
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67778}