Win64 unwind data can specify a language-specific handler function which is
called as part of the search for an exception handler, as described in
https://docs.microsoft.com/en-us/cpp/build/exception-handling-x64?view=vs-2019.
This is used for example by Crashpad to register its own exception handler for
exceptions in V8-generated code.
There is a problem in the code that may cause a freeze on abort: in file
\deps\v8\src\unwinding-info-win64.cc in function CRASH_HANDLER_FUNCTION_NAME the
line:
    return EXCEPTION_CONTINUE_SEARCH;
should be
    return ExceptionContinueSearch;

These constants are both used in the context of Win32 exception handlers, but
they have different semantics and unfortunately different values:
EXCEPTION_CONTINUE_SEARCH (=0) should be returned by an exception filter
while a language-specific handler should return an EXCEPTION_DISPOSITION value,
and more precisely ExceptionContinueSearch (=1) in this case.

Bug: v8:9295
Change-Id: I1a3aaabf357e52a909611814f1ea013cf652ae06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1629795Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#61867}

Plan to flip to ship in early June (after m76 branch) for chrome m77.
Spec: https://tc39.github.io/proposal-unified-intl-numberformat/
Design Doc: https://goo.gl/ZAtL1f
I2I: https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/Intl%7Csort:date/blink-dev/q3U7sPOG1uo/M7XZU7fxAwAJ

Tests:
intl/number-format/unified/*
test262/intl402/NumberFormat/* (tests with Intl.NumberFormat-unified)

Bug: v8:8515
Change-Id: Ica4108d6ffcc8819940cb6cecb15d852ae7cdf14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1629407Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61866}

Instead of generating one CodeStubAssembler-like class per namespace,
Torque-generated macros are now free-standing functions not included
from CSA code, and explicitly exported macros become part of the new
TorqueGeneratedExportedMacrosAssembler, which CodeStubAssembler
inherits from, thus making them available to all CSA code.

Structs are now defined in a new header csa-types-tq.h as free-standing
types with the prefix "TorqueStruct".

This is a preparation for generating per Torque-file instead of per
namespace.

Change-Id: I60fadc493a63f85d1d340768ec6f11ae47be0cb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628787
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61865}

This is a reland of 4b86fea5 with
copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
(bug led to holes in new space, which was crashing reproducibly
on the ia32 bot).

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
>
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
>
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
>
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
>
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

Tbr: petermarshall@chromium.org
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61864}

The code that copies code bytes from a MacroAssembler into a buffer in a
CodeRangeUnwindingRecord struct (used to store stack unwinding data) has an
error: it copies the whole MacroAssembler buffer size, not just the size of the
compiled instructions into an "exception thunk" array.
This has no real bad effects, because a CodeRangeUnwindingRecord is stored at
the beginning of a page reserved at the beginning of an isolate code range, but
it is quite bad and we need to fix it.

Bug: v8:3598
Change-Id: I0df0cf0173561cc939e6431bc0f01ef040fc189e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1629310Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#61863}

Improve micro-benchmark by ~5x
Before:
ApplySpreadLiteral
ApplySpreadLiteral-Numbers(Score): 279
SpreadCallSpreadLiteral
SpreadCallSpreadLiteral-Numbers(Score): 285

After:
ApplySpreadLiteral
ApplySpreadLiteral-Numbers(Score): 1074
SpreadCallSpreadLiteral
SpreadCallSpreadLiteral-Numbers(Score): 1009


Bug: v8:6831
Change-Id: Ifd676ca13d5b7e86afc1578636fdd4dc2733c474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628244
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61862}

Consider embedder allocation rate when scheduling full garbage
collections.

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

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

On newer compilers the {operator delete} with explicit {size_t}
argument would be instantiated for {CompilationState} and used in the
destructor of {std::unique_ptr<CompilationState>}. The {size_t}
argument is wrong though, since the pointer actually points to a
{CompilationStateImpl} object.
Hence avoid this operator from being created by explicitly providing an
{operator delete}.

R=ulan@chromium.org

Change-Id: I54fef07179b3106f3154ddd43df040fe8e3cdde8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631426Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61859}

This seems like a very specific flag which is rarely used. It not only
adds local overhead, but also requires an additional parameter at
{BuildGraphForWasmFunction}.
Thus this CL removes it completely. Interested parties can still measure
timing locally.

R=titzer@chromium.org

Bug: v8:9183
Change-Id: I5f152cdb9456d1001ed38722d44c71cf5ae44ae3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631420Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61858}

Add test harness so that we can avoid all this boilerplate for common
tests in the future. Use it for the existing perfetto tracing test.

Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: Iddc716aade3eef2431bcc7eaa8b8b6502edaaa00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631418
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61857}

This reverts commit 4b86fea5.

Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
> 
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
> 
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
> 
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
> 
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org

Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61856}

As the next step in supporting huge typed arrays in V8, this moves the
external/data pointer from the FixedTypedArrayBase backing store to the
JSTypedArray instance itself, and replaces the special backing stores
with a plain ByteArray (removing all the code for the FixedTypedArrayBase
class hierarchy). By doing so, we can drastically simplify the system
around typed arrays.

Note: Several places in the code base used to check the instance type
of the elements backing store of a JSTypedArray instead of checking the
elements kind on the JSTypedArray map directly. Those had to be fixed,
since the backing store is now always a ByteArray.

Drive-by-fix: Move all the typed elements access related code into the
elements.cc file to properly encapsulate the accesses.

Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61855}

Add a new abstract class TraceEventListener which is just an interface
for consuming trace events. This separates the V8-specific stuff that
an actual perfetto consumer needs to do e.g. handling the has_more flag
and signalling back to the controller with a semaphore.

This is a change from the previous plan of making the PerfettoConsumer
class sub-classable to implement custom consumption of trace events.
This will be difficult when the consumer is created outside of the
PerfettoTracingController as we can't hook up the
consumer_finished_semaphore_ that belongs to the controller.

Now the PerfettoTracingController is responsible for the Consumer life-
cycle and hides it entirely from callers. We add the
AddTraceEventListener() method to allow callers to register a listener
either for testing or a JSON listener for real tracing.

This lets us write tests that can store all the trace events in memory
without first converting them to JSON, letting us write test more
easily. There's an example test add to test-tracing - more tests using
this style will follow.

Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: I2d2b0f408b1c7bed954144163e1968f40d772c1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628789
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61854}

Bug: v8:9103
Change-Id: I7ff6bb0032fd5d81339401bbf8276baf19af8489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631417
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61853}

This moves the platform-specific WriteByteChunk (& friends) into
platform-specific embedded file writers.

Bug: v8:9103
Change-Id: I0113c90dbf661a39dabe62b420cf6a160ee1be1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631412
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61852}

This adds a reflective function to retrieve the function type of an
exported or constructed WebAssembly function object. Note that this
first implementation only supports exported functions for now, the
support for constructed functions will be done as a follow-up.

R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742

Change-Id: I38a16972d8437521993992ca20887c47c7c6b99b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627989Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61851}

The win64-specific unwinding info writer should not be part of the
generic EmbeddedFileWriter class. Let's hide it in the platform-specific
writer.

Bug: v8:9103
Change-Id: Ifc4f8b326f07e037b6876e0592cb70b8281edb9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627536
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61850}

This replaces all typedefs that define types and not functions by the
equivalent "using" declaration.

This was done mostly automatically using this command:
ag -l '\btypedef\b' src test | xargs -L1 \
     perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'

Patchset 2 then adds some manual changes for typedefs for pointer types,
where the regular expression did not match.

R=mstarzinger@chromium.org
TBR=yangguo@chromium.org, jarin@chromium.org

Bug: v8:9183
Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61849}

The `->` operator should be changed to `.` after
https://chromium-review.googlesource.com/c/v8/v8/+/1624209

Change-Id: Ie16adaa17bfc7caaa589ed3881a8716e98ea36b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628793Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#61848}

Bug: chromium:966832
Change-Id: Ie89dbbc1d92f746547aecf4752b6b3189bc251aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627987
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61847}

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

When allocating large arrays on 32-bit systems, the length conversion
caused the work array capacity to become negative. As the sort range
is currently clamped at kSmiMaxValue anyway, the fix is to also
clamp the work capacity to that value.

R=jgruber@chromium.org

Bug: chromium:967065
Change-Id: I9ea60464c5b7f3796c5389cbaf668b990eddecf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630672
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61845}

R=jarin@google.com, tebbi@google.com

Change-Id: Ic64ca132178f189a6d78a73ed18150ae503dd9a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617936
Auto-Submit: Georg Schmid <gsps@google.com>
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61844}

Bug: v8:9103
Change-Id: I9a11bd99eb3f2b082749cf6a497ffe759216ad22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627347
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61843}

This reverts commit 384a51da.

This hack is both broken (builtins now have individual symbols and no
longer resolve to v8_Default_embedded_blob_) and useless (profview
seems to detect builtins just fine without it).

Bug: v8:6666
Change-Id: I264b4de31124f1657f4dc570590eb73e53aa08d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627344Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61842}

Currently, all background compile tasks run for 50ms, then they all
publish their results and restart. This results in significant
contention during the publish phase.
This CL introduces an atomic counter on the {CompilationStateImpl} to
distribute the deadline more evenly: Each task executes between 50ms
and 200ms, and tries to pick a deadline 5ms after the previously
assigned deadline, if this lies within these boundaries. This speeds up
publishing significantly and saves several percent compilation time
overall.

R=mstarzinger@chromium.org

Bug: v8:8916
Change-Id: Id32a5a72c1dd44d30df2ea09643b2a6e4f436944
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627984
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61841}

The category for wasm trace events is "disabled-by-default-v8.wasm",
generated by {TRACE_DISABLED_BY_DEFAULT("v8.wasm")}.
This CL fixes two events that used the category without the
"disabled-by-default-" prefix, and adds two more trace events to make
code GC more visible in the trace.

R=mstarzinger@chromium.org

Bug: v8:8217
Change-Id: Ib20d9caec9e55013acbeb604f91a63e8a557f30c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627982
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61840}

R=ahaas@chromium.org
CC=​titzer@chromium.org

Bug: v8:9231
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Change-Id: I3de9c839ad43ab37c69b622ccf221dfc429c2e2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605732
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61839}

This is a reland of e588ff10

The only change over the original CL is found in JSCreateLowering::AllocateFastLiteral. We now guard against boilerplate values for unboxed double fields that *look* like legitimate initial values, but should really be kHoleNanInt64 instead.

The underlying problem certainly existed before, but an invariant added to LoadElimination in this CL caused a Chromium layout test to fail. The change in this reland is therefore a workaround, the root cause remains to be fixed. Specifically, we find that a pointer to the undefined value oddball is sometimes reinterpreted as a double and assigned as a boilerplate value. @jarin suspects that this stems from in-place map updates.

Original change's description:
> Make LoadElimination aware of const fields (Part 2; stores)
>
> Adds const information to store field accesses and uses it in load elimination
>
> Change-Id: I00765c854c95c955dabd78557463267b95f75eef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Schmid <gsps@google.com>
> Cr-Commit-Position: refs/heads/master@{#61796}

Change-Id: Ie388754890024a3ca7d10c9d4d7391442655b426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630676Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#61838}

Drive-by: fix an #include that the gcov bot is missing

Bug: v8:9183
Change-Id: I35d1b4e346a56799a5f49b7059a658d5ccfe75ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627548Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61837}

R=sigurds@chromium.org

Bug: v8:9247
Change-Id: I25743f048e3e6cd22a18e003e77c8b78f147b630
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630680Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61836}

COW arrays were previously handled in the C++ pre-processing runtime
function.  The Torque version forgot a "EnsureWritableFastElements".
This CL fixes that.

Bug: chromium:967254
Change-Id: Ifbf89e57cfe724e61316b8abc226f7e8a262fce2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630675Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61835}

This CL removes the await-optimization-flag, that is no longer needed,
since the feature is considered web compatible.

Bug: v8:8267, chromium:893469
Change-Id: I046f003f9ed6853d713b825c436fe5f0a1e5a0a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630677Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61834}

Bug: v8:9183
Change-Id: Id2ae3ee0a53133eaf41e28fcadc681edf5ffb382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630673Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61833}

Pass test262 change in Proxy: defineProperty, deleteProperty, getOwnPropertyDescriptor.

Bug: v8:9228
Change-Id: Id9a2c8dcbfcf68ed2837eb6d5042abcbce7ab0ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1626474
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61832}

TBR=tmrts@chromium.org

No-Try: true
Change-Id: I9a7a7bd623399575f8c31b9566744f7510648775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630147
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61831}

TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org

Bug: v8:9247
Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61830}

Consider the case that uloc_toLegacyType may return nullptr while
the specified keyword value cannot be mapped to a well-formed legacy type.

Bug: chromium:966285
Change-Id: I40511c54e4835599c002f1c678121341276a4e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627902
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61829}

Bug: v8:7793
Change-Id: Ic485dc953c80d055ff190b8be2a5434e5cdbeb5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624214
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61828}