- Add new Builtin enum
- Move Builtins::Name:kXXX to Builtin::kXXX
- Update existing code

Follow CLs will unify the mix of using int builtin-ids and
Builtins::Name to only use the new Builtin enum and changing it to
an enum class.

Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74995}

Bug: chromium:1216437
Change-Id: Ib8439aefc778beefed4dc40290473311cc23d5f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944937Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74994}

This will allow Fuchsia tests to be run on v8 CI

Bug: v8:11843, chromium:934932
Change-Id: I516329d8f29d9c94d46aa010fa729fa3ca0993ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2935024
Commit-Queue: Chong Gu <chonggu@google.com>
Auto-Submit: Chong Gu <chonggu@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74993}

The flag --trace-ignition-dispatches has been broken for a long time,
since it was not designed to work with bytecode handlers that are
generated ahead of time by mksnapshot. This splits the existing
--trace-ignition-dispatches logic into two separate parts:

1. A gn argument which instructs mksnapshot to include dispatch counting
   in the bytecode handlers, and ensures that the Interpreter allocates
   the array of counters, and
2. A runtime flag which enables the ignition-statistics extension which
   implements the JS-accessible function getIgnitionDispatchCounters().

Change-Id: I89323425697f5641451f67b9ddcc0303b8ca209f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2937564Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74992}

xmm0 and xmm1 are used to save/restore values in asm builtins, but they
were not saved before calling RecordWrite, which calls C++ code.
Instead of passing SaveFPRegsMode::kSave to RecordWriteField, which
would save/restore all FP-regs, this CL explicitly saves/restores the
FP-regs we rely on beyond the C-Call.

Bug: chromium:1216295
Change-Id: Ifcc7ce4e8819303ffb79576a88304df2e3a6cc4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944427Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74991}

Add flag --lazy-feedback-allocation to prevent NumFuzz errors.

Bug: v8:11853
Change-Id: I5170ef9db374e168cf248b86dbed3c3e7c87f826
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944428Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74990}

Left-trimming only works when there is a single reference to the
backing store from the JS object. Main thread handles are an exception
to this rule because it is not feasible to ensure that no such
leftover handles may store such stale pointers.

FixStaleLeftTrimmedHandlesVisitor clears such references
in main thread handles, such that the GC never tries to visit them. This
CL renames this class to ClearStaleLeftTrimmedHandlesVisitor to
emphasize that such slots are cleared rather than "fixed up" to point
to the new object start.

Previously ClearStaleLeftTrimmedHandlesVisitor was used for local
and persistent handles as well. Starting with this CL, stale references
to left-trimmed objects are only allowed in main thread handles.
https://crrev.com/c/2928502 enabled us to be more restrictive here.

Change-Id: If4db0630f1df2d6c3fe5f242bf866c57a8ae2969
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944807Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74989}

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

- Introduce proper TickLogEntry and use a separate Timeline object
- Update the main rendering to use SVG for speed
- Separate custom-elements: timeline-track-map and timeline-track-tick
- Revamp flame-chart drawing
- Enable map-transitions overlay
- Use mouse position to infer current log-entry instead of individual
  event handlers
- Fix first timelineLegend column header
- Fixing scrollbar-color for FireFox

Change-Id: I7c53c13366b3e4614b1c5592dfaa69d0654a3b5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944430
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74987}

This fix makes ObjectLiteral::CalculateEmitStore work correctly.

Bug: v8:11810
Change-Id: I60f3d5cb657f4b2ca574d5224c8f1cb7a8216354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917040Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74986}

Use new Script.prototype.update method to set the url and the script
source.

Bug: v8:11850
Change-Id: I555d4d0158cdacb7cb42efa385371454542fc2f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944438Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74985}

We have recursive calls such ThinStrings where we go String::Get into
ThinString::Get into String::Get again for the internalized string. If
we need to, we would acquire the StringAccessGuard in the first
String::Get and it wouldn't be needed to be re-acquired for the second
String::Get. Trying to re-acquire it would in fact be an error since we
are already holding the lock.

The code, however, didn't know if we acquired it or not. It was working
correctly due to the way the methods were defined and called. By passing
down the access guard through the Get() calls we make this interaction
explicit.

Also add some thin string tests to test the interaction.

Bug: v8:7790
Change-Id: I1181edec1e802cb754c4d1d1ac268577257b92f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2936598
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74984}

Change-Id: Ia1dfb428e5518343252300bf4323f24a20bb7f2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939539
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Reviewed-by: Brice Dobry <brice.dobry@futurewei.com>
Cr-Commit-Position: refs/heads/master@{#74983}

A spec test (wasm-js/global/value-get-set) requires
WebAssembly.Global.value.set to throw an exception if it is called with
0 arguments. The implementation in V8, however, just checked if the
first parameter is `undefined`. This implementation indeed threw an
exception if 0 arguments were provided, but it also threw an exception
when `undefined` is provided as a parameter. This, however, violates
the spec, because globals can be reset to `undefined`.

With this CL we replace the checking for `undefined` by checking the
length of the arguments that get provided.

R=ecmziegler@chromium.org

Bug: chromium:1211342
Change-Id: Ic87a0b369dea3e49eddb8f71f2c29dc6a8f5f558
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940901Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74982}

instead of recursive. JS code can construct very long chains of
nested bound functions or proxies, where the previous recursive
implementation could run out of stack space.

Fixed: chromium:1214616
Change-Id: I764718f03030d22c0873b3ed05277d4317789093
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933668
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74981}

When growing a memory without a maximum, we should still check against
the spec'ed limit, to avoid an overflow when computing the new number of
pages.

R=ahaas@chromium.org

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

While no scavenger thread reads the content of an object copied by
another thread, we still need memory ordering in order to read the page
flags for a forwarded object.

Change-Id: I831e9dccb03d32daf3c4847613614d26533ba825
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944436Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74979}

This reverts commit 6596e8c6.

Reason for revert: Main bug was fixed.

Original change's description:
> [infra] Switch back to Xenial on some bots
>
> This tests the hypothesis that the current timeout problems are on
> Bionic bots only.
>
> Bug: v8:11818
> Change-Id: I68f84cda52ca392fbda5a400eb2bf136b7ee85a3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916816
> Auto-Submit: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74747}

Bug: v8:11818
Change-Id: Ib5f952dc6f23f3a98bb1d79ae5ce689e288d6727
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940897
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74978}

.. and replace them by elements read directly from the heap object.

With this change, consistency between `map` and `elements` is
no longer guaranteed. Users were updated, when necessary, to deal
with this, e.g. by being more careful not to read out of bounds,
by inserting new `actual_elements == elements_constant` runtime
checks, or through a new compilation dependency that verifies
unchanged elements at finalization time.

Drive-by: inline GetElementsKind into callsites.

Bug: v8:7790
Change-Id: Ifba78182e185ff0d4e954e3be52f0eb24328c853
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909655Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74977}

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

We currently take the sample at the moment the isolate is created. At
that point, the embedder callback for taking samples is not installed
yet. Hence delay taking the sample until the first module is created.
This will only take samples for isolates that actually use wasm, which
will reduce the overall number of samples, but will give a better
picture of PKU support for Wasm.

R=jkummerow@chromium.org
CC=dlehmann@google.com

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

This reverts commit 79d63a5e.

Reason for revert: Breaks predictable: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20predictable/36887/overview

Original change's description:
> [wasm] Remove all implications from --predictable
>
> In predictable mode, we want to execute the same code as otherwise,
> modulo timing. Hence remove any implications which change behaviour
> (like tier-up or asynchronous compilation).
> Note that --predictable is a debugging flag, so the configurations does
> not need to "make sense" in production.
>
> R=​ahaas@chromium.org
>
> Bug: v8:11848
> Change-Id: If74fbacadeb087d977922c41f33fd18738b50ded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940898
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74973}

Bug: v8:11848
Change-Id: I20eaf665e8ce63af8aeffe3bac7a45372ad6ab7b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944434
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@{#74974}

In predictable mode, we want to execute the same code as otherwise,
modulo timing. Hence remove any implications which change behaviour
(like tier-up or asynchronous compilation).
Note that --predictable is a debugging flag, so the configurations does
not need to "make sense" in production.

R=ahaas@chromium.org

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

Change-Id: Id502aa02a778d17c32996b0438ac3a7c85166430
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940892Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74972}

Introduce EmitTSANStoreOOLIfNeeded methods which make it easier on the
eyes in code-generator.cc.

Also pass along the size, which lays the groundwork for the other
instructions e.g. kX64Movq since we don't require the store to be a
Tagged one. This creates new builtins (since we now have a version with
32 bits and another one for 64 bits stores). We can extract the common
code in builtins-internal-gen.cc to de-duplicate the common code.

Bug: v8:7790, v8:11600
Change-Id: I81d80b852ec96b94d170a20f6d61621743b74b32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933664Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74971}

This is a reland of 5fd38582. It adds
back all recursive implications (via --single-threaded), such that we
can remove them individually in follow-up CLs and watch the state of
the predictable bot.

Original change's description:
> [flags] Predictable should not imply single-threaded
>
> The --predictable flag is often used to reproduce issues, and having it
> imply --single-threaded can change decisions like which compiler(s) to
> use. This is because --single-threaded is meant to be set by embedders
> (hence we do our best to support single-threaded execution), whereas
> --predictable is a testing-only flag which should not change semantics
> too much. The fact that --predictable executes everything in a single
> thread is already implied by the PredictablePlatform.
>
> R=ahaas@chromium.org, machenbach@chromium.org
> CC=​jkummerow@chromium.org
>
> Change-Id: Ic174dd59dfdbd6aa1a410f983db05db26c944cd5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919828
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74822}

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

This is a reland of 81dd3f42,
which was a reland of 59eff3bf

Original change's description:
> [bigint] Karatsuba multiplication
>
> The Karatsuba algorithm is used for BigInts with 34 or more internal
> digits, and thanks to better asymptotic complexity provides greater
> speedups the bigger the inputs.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782283
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74916}

Bug: v8:11515
Change-Id: I08f7d59dfa39fb3b532684685afd9fa750e0e84e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933666Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74969}

Bug: v8:11525
Change-Id: I0ac9f252e0de16480036e3630edf7efefe8d8571
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928501Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74968}

Bug: chromium:1213927
Change-Id: I85f5559863524717355ec61694ce007a2be7c8a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2931799Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74967}

Since there is only a single thread in predictable mode, we should never
wait for more work. That would be an immediate deadlock.
This CL adds code to never wait, and instead checks after processing all
messages that we would not need to wait (i.e. that all work was
completed). This turns deadlocks into FATAL errors.

R=ahaas@chromium.org

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

Strict equality checking of ValueTypes only made sense before
reference types came along.

Change-Id: I632f541328cb27ae87a5e3daccd4ffb9cfc8a502
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928513
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74965}

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

Prepare method by taking an object as argument. In the future we can
optimize this method by only sweeping the object's page.

Bug: v8:11837
Change-Id: Ife1ee7949bfaf590dcc305cc4d03aa1813c07b76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940888Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74963}

This fixes a little mistake from https://crrev.com/c/2182453. In
predictable mode (where we do not have any threads for executing
background work) we are executing everything on the main thread, but we
should never wait for background work to be spawned. Otherwise we can
deadlock if the last background task spawned new foreground work, but we
keep waiting for more background work to arrive.

Generally, any blocking in predictable mode will block forever, because
there is no one to spawn any work concurrently (foreground or
background). But the blocking for foreground work has to be there for
non-predictable mode, thus keep it for now, and only remove waiting for
background work.

R=ahaas@chromium.org

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

This reverts commit d1e1f1be.

Reason for revert: Main bug was fixed.

Original change's description:
> [infra] Switch back to Xenial on a slow variant
>
> This is to mitigate flaky timeouts due to memory problems on some
> Bionic bots.
>
> Bug: v8:11818
> Change-Id: I4758f0f167b94d81f43e183a5599a39d8545b4e1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922245
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Auto-Submit: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74824}

Bug: v8:11818
Change-Id: I9719cbcd074de44cd5fb981c40f46bf4e10adee0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940895
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74961}

This aids debugging as it gives the root set a name.

Bug: chromium:1164553, chromium:1186901
Change-Id: I2c2aed369823b059629b35bb170b4966b47156d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933661
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74960}

The tests are not compatible with the --stress-background-compile flag.

Bug: v8:11821
Change-Id: Iecef6a2838109fddc9f0ecc145a9f8971bc9bc3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918214Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74959}

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/092e09c..8bf7a0b

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

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

This is a reland of b0c70710

The first CL got reverted because of build errors. This CL replaces the
remaining usage of is_local_space() with is_compaction_space().
Supposedly this was a leftover because https://crrev.com/c/2928189
landed at roughly the same time.

Original change's description:
> [heap] Remove unused LocalSpace class
>
> LocalSpace was introduced for off-heap spaces with concurrent bytecode
> compilation finalization. However, finalization ended up using
> LocalHeap for concurrent allocations. LocalSpace is therefore unused
> and can be removed.
>
> This CL removes LocalSpace and renames all mentions of local space to
> compaction space. Compaction space was the only local space left.
>
> Change-Id: I12a8a2724f777a77ddb9957fe2d8e89febfebbaf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930169
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74914}

Change-Id: I993c47fe85f4140f5d6137afde2653a48047cafb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939983Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74957}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/74cfeda..e353b02

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

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