Whenever more then one value is pushed to the stack, we need to execute
a check for growing the stack first (since https://crrev.com/c/2431525).
This CL adds two missing checks.

R=thibaudm@chromium.org

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

Bug: chromium:1052746
Change-Id: I6c1f888ed9a7f27d43872e24f8d8cf353a103f1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461740
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70479}

The call to "GetSpilledRegistersForInspection" was invalidated by the
call to "GetUnusedRegister" a few lines below.

R=clemensb@chromium.org

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

The index to be traced can be a full (platform-dependent) pointer sized
integer now. This CL prepares memory tracing for that.
As a drive-by, the "address" field is renamed to "offset", or
"effective_offset", depending on the situation.

R=manoskouk@chromium.org

Bug: v8:10949
Change-Id: I1fabfdb57835f041e1310a4eb4024d6254c08752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465825Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70477}

Rename the flag --liftoff-extern-ref to
--experimental-liftoff-extern-ref to keep the fuzzer from using it.
The implementation is not complete yet, and the next steps may take a
bit.

R=clemensb@chromium.org

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

A JSObject's own properties were always printed as if all were stored
in the 'properties' backing store, even if some of them were stored in
the descriptor array and/or in-object. This CL tries to make the output
a bit clearer.

Change-Id: I03d05bdd530cc4c534c945aa08bad20edc3bbcd7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466119
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70475}

Use monotonic times for logging with --predictable.

Bug: v8:10937, v8:10966, v8:10668
Change-Id: I3d4f0d48375f6f5d9fa375cf5393ff3afee7c0b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465829
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70474}

We now remember whether the memory was 64 bit, in in this case force the
index value to be an i64 instead of an i32.

This is only the decoding part of this change. TurboFan and Liftoff will
have to be fixed separately to handle the i64 values correctly.

R=manoskouk@chromium.org

Bug: v8:10949
Change-Id: Ia504e7eb5a2a55caf8dfdbd0833481ef590c55bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461239
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70473}

The generic wrapper will be the baseline variant of the JavaScript-to-
WebAssembly wrapper. Enabling it in the nooptimization variant gives it
test coverage.

R=clemensb@chromium.org

Bug: v8:10701
Change-Id: I37d1f767c61ff70e103d1742ef84f874c3804d7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461240
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70472}

Code objects for builtins are immortal and immovable and can thus be
dereferenced like read-only-objects.

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

... to expose the memory region containing embedded builtins. Similar
to `GetCodeRange`, which does the same for on-heap V8 Code objects.

Bug: v8:11001
Change-Id: I1aa3ae650f161cabb410c61dbb6d364908370f8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465461
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70470}

Change-Id: I3f5dbb0fbae3862a6da4146b83e49986c8be3bdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467015Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#70469}

This disables the following features for --enable-third-party-heap:
- inline allocation: all allocation are directed to runtime for now
  until we have support for TPH inline allocation.
- allocation site pretenuring: this feature relies on ephemeral
  memento objects placed after ordinary objects and is tightly coupled
  with V8's GC.
- allocation folding in TurboFan: this feature assumes that objects
  of different size and type can be allocated on the same page using
  bump-pointer allocation.

Bug: v8:9533
Change-Id: Idbdf1dac566f37db379e5d4b43e0741886f4e69b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463004
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70468}

Bug: chromium:1137528
Change-Id: I1f00cdbe7af97e56f234cc140dc0039be346690a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465836Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70467}

Always spend 1ms per iteration.

Previously if the profilerthread took a long time to start up then we
would skip through iterations and potentially not gather enough samples.

This forces each iteration to take 1ms.

Bug: v8:10996
Change-Id: I0dd7bb7e31636c9ebf5dd99110c8a976cbc8f045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461727
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70466}

CreateFrameFromInternal always creates StackFrame from the frame at the index zero,
which is fine for the usage in Trap::origin, but is a bug for Trap::trace

Change-Id: Ia9471f600c5165ffc1c165b2f114b40acbe5b1e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465353
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70465}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3110f72..18a5f87

TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

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

These are still not in proposal, so they should be behind the post-mvp
flag.

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

On AVX, many instructions can have 3 operands, unlike SSE which only has
2. So on SSE we use DefineSameAsFirst on the dst. But on AVX, using that
will cause some unnecessary moves.

This patch changes a couple of F32x4 and S128 instructions to remove
this restriction when AVX is supported.

We can't use AvxHelper since it duplicates the dst for the call to the
AVX instruction, which isn't what we want. The alternative is to
redefine Mulps and other functions here, but there are other callsites
that depend on this duplicated-dst behavior, so it's harder to change.
We can migrate this as we move more logic over to non-DefineSameAsFirst
for AVX.

With the meshopt_decoder.js in the linked bug, it removes 8 SIMD movs
(from a function that has 300+ lines of assembly.)

Note that from agner's microarchitecture.pdf, page 127, "Elimination of
move instructions", many times such moves can be eliminated by the
processor. So this change won't speed up perf, but it helps a bit with
binary size, and decoder pressure.

Bug: v8:10116,v8:9561
Change-Id: I125bfd44e728ef08312620bc00f6433f376e69e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465653Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70462}

This implements i8x16.popcnt on arm64 and interpreter.

Bug: v8:11002
Change-Id: Ia94a053d7e0a0c800057ac80865ba6f86ac7caf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461058Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70461}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7e6351e..3110f72

TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

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

Implement on interpreter and x64.

Bug: v8:10997
Change-Id: I3537ce54e1b56cc3b04d91cb07c430c35b88c3aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459109
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70459}

This reverts commit 5e5eaf79.

Reason for revert: Failure on V8 Linux gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8929?

Original change's description:
> [csa] Fix semantics of PopAndReturn
>
> This CL prohibits using PopAndReturn from the builtins that
> have calling convention with arguments on the stack.
>
> This CL also updates the PopAndReturn tests so that even off-by-one
> errors in the number of poped arguments are caught which was not the
> case before.
>
> Motivation:
>
> PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> dropping ALL JS arguments that are currently located on the stack.
> Disallowing PopAndReturn in builtins with stack arguments simplifies
> semantics of this instruction because in case of presence of declared
> stack parameters it's impossible to distinguish the following cases:
> 1) stack parameter is included in JS arguments (and therefore it will
>    be dropped as a part of 'pop' number of arguments),
> 2) stack parameter is NOT included in JS arguments (and therefore it
>    should be dropped in ADDITION to the 'pop' number of arguments).
>
> This issue wasn't noticed before because builtins with stack parameters
> relied on adapter frames machinery to ensure that the expected
> parameters are present on the stack, but on the same time the adapter
> frame tearing down code was effectively recovering the stack pointer
> potentially broken by the CSA builtin.
>
> Once we get rid of the arguments adapter frames keeping stack pointer
> in a valid state becomes crucial.
>
> Bug: v8:5269, v8:10201
> Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70454}

TBR=tebbi@chromium.org,ishell@chromium.org

Change-Id: I2673982a8f51cbecf421af11b0ce5ad5031fb406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465656Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70458}

This flag allows you to filter printing Wasm code to one particular
function index.

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

Load lane loads a value from memory and replaces a single lane of a
simd value.

This implements the load (no stores yet) for x64 and interpreter.

Bug: v8:10975
Change-Id: I95d1b5e781ee9adaec23dda749e514f2485eda10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444578
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70456}

These instructions are not in the proposal, and will be unlikely to be
requested (poor performance, insufficient use cases). As we get more
instruction suggestions, these are sitting around on useful opcodes and
we have to play musical chairs every time we prototype a new
instruction.

Bug: v8:10933
Change-Id: Ic7ce4e514c343d821f76b8c071e41f9bddfbd1ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2457669Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70455}

This CL prohibits using PopAndReturn from the builtins that
have calling convention with arguments on the stack.

This CL also updates the PopAndReturn tests so that even off-by-one
errors in the number of poped arguments are caught which was not the
case before.

Motivation:

PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
dropping ALL JS arguments that are currently located on the stack.
Disallowing PopAndReturn in builtins with stack arguments simplifies
semantics of this instruction because in case of presence of declared
stack parameters it's impossible to distinguish the following cases:
1) stack parameter is included in JS arguments (and therefore it will
   be dropped as a part of 'pop' number of arguments),
2) stack parameter is NOT included in JS arguments (and therefore it
   should be dropped in ADDITION to the 'pop' number of arguments).

This issue wasn't noticed before because builtins with stack parameters
relied on adapter frames machinery to ensure that the expected
parameters are present on the stack, but on the same time the adapter
frame tearing down code was effectively recovering the stack pointer
potentially broken by the CSA builtin.

Once we get rid of the arguments adapter frames keeping stack pointer
in a valid state becomes crucial.

Bug: v8:5269, v8:10201
Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70454}

Use a doubly-nested switch on SimdType for conversions, this ensures
that we handle all possible cases (and we actually missed one,
converting i64x2 -> f32x4, which is added in this patch.)

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

Manual copy and paste of all code found in the namespace base. I didn't
change any of the implementation code. Pull in a new file for optimized
ARM implementation.

Added a list of adaptions made to document what is different from
chromium.

Change-Id: I88b4af45437506cf57755e48fdfc88027a5aed33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436610
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70452}

For turboprop, it's a better tradeoff to reuse the code than
specialising the code for a particular closure especially given we
optimize quite early when compared to Turbofan.

Bug: v8:9684
Change-Id: Icf5d8548bbdcac9e202dcf44c68e06cc4c732ba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461242
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70451}

Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/23ef533..e0f2b84

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1cb6993..7e6351e

Rolling v8/third_party/aemu-linux-x64: FgthknmEoQugl3GqOyqz_RsAjIMmeLsa960mZcmhE9UC..PL87Lj_q7GOEzYJ2eJIJAzMtQbuLWVnmjDQPqfu2O64C

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d82d30d..cd2eebd

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/1407cfd..b073999

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f513a0b..7e5979b

Rolling v8/tools/luci-go: git_revision:83c3df996b224edf5061840744395707a0e513e7..git_revision:576741d3eed0fa33971fb34cd823650e6f5b47fb

Rolling v8/tools/luci-go: git_revision:83c3df996b224edf5061840744395707a0e513e7..git_revision:576741d3eed0fa33971fb34cd823650e6f5b47fb

Rolling v8/tools/luci-go: git_revision:83c3df996b224edf5061840744395707a0e513e7..git_revision:576741d3eed0fa33971fb34cd823650e6f5b47fb

Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/44c13d7..d46ea76

TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

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

This test allocates a large mapping and splits into kThunkBufferSize
areas that it needs to be able to change permissions on. So
kThunkBufferSize needs to be set to the largest page size possible,
which is 64k at the moment.

It doesn't matter if kThunkBufferSize is larger than the actual page
size.

Bug: v8:10808
Change-Id: I3a8947f04a7ec25be49a54015cd128e901065ea6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463404Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70449}

According to this change in chromium's DEPS
https://chromium-review.googlesource.com/c/chromium/src/+/2446832

Bug: chromium:1137317
No-Try: true
No-Presubmit: true
Change-Id: I2b9e804f151834b58b77db1aca591e2eade91243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465826
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70448}

Bug: v8:10201
Change-Id: I86cd6b73787cea307013dd311d048b20459ad573
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465052Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70447}

Cleanup code to factor out bit-checks on register allocations to a
seperate RegisterBitVector class.

BUG=v8:9684

Change-Id: I33306a858da252d0be76eecaa9ea47b9b53f088b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464936Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70446}

Fix a crash/hang that occurred when deleting a snapshot during the
GC that is part of taking another one.

Specifically, when deleting the only other snapshot in such
a situation, the `v8::HeapSnapshot::Delete()` method sees that there
is only one (complete) snapshot at that point, and decides that it is
okay to perform “delete all snapshots” instead of just deleting
the requested one. That resets the internal string lookup table
of the heap profiler, but the new snapshot that is currently in
progress still holds references to the old string lookup table,
leading to a use-after-free segfault or infinite loop.

Fix this by guarding against resetting the string table while
another heap snapshot is being taken, and add a test that would
crash before this fix.

This can be triggered in Node.js by repeatedly calling
`v8.getHeapSnapshot()`, which provides heap snapshots as weakly
held host objects.

Change-Id: If9ac3728bf79114000982f1e7bb05e8034299e3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464823Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70445}

See: https://github.com/nodejs/node/pull/35415
Change-Id: I5d77ae202d4bbfb0971246fe5de9c0ad17c485ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459491Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jiawen Geng <technicalcute@gmail.com>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70444}

This has been broken ever since we added multiple timeline-tracks.

Drive-by-fix: Rename selectionMouseMove to selectTimeRange.

Bug: v8:10644
Change-Id: Icff06a2d636a4a7302ac406f99e1012be4c7f25f
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463240
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70443}

Clean-ups:
 * Remove the detaching of persistent handles from the LocalHeap if the
main thread will not get the handles from the background thread.
 * Remove unused isolate member.
 * Make members private/protected as needed.

Bug: v8:7790
Change-Id: I23bf4a41124bd04d4a848edfa1ef8f9e8e77182c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463234Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70442}

This is a reland of e2408c25

Changes since last time: also accept CRASH test results. For some
reason, the CHECK failure is detected as a CRASH on mac bots.

Original change's description:
> [regexp] Protect against reentrant RegExpStack use
>
> Irregexp, and in particular the RegExpStack, are not reentrant.
> Explicitly guard against reentrancy.
>
> Bug: chromium:1125934
> Change-Id: I0fc295f6986a89221982e6a2ccefed46193974f6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460820
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70436}

Tbr: yangguo@chromium.org
Bug: chromium:1125934
Change-Id: I2116ca5944c49f6114228d4402847bdd426bdd7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465823Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70441}