This reverts commit 9b0d5cb1.

Reason for revert: Seems to fail on gc-stress bots (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/43472/overview)

Original change's description:
> [ext-code-space] Fix Code vs non-Code comparisons
>
> When external code space is enabled comparing Code and non-Code objects
> by looking at compressed values is not always correct. Such an approach
> works only for comparing Code vs Code objects or non-Code vs non-Code
> objects.
>
> This CL instroduces SLOW_DCHECK into Object comparison operators to
> ensure that such a comparison is allowed. Also, this CL instroduces
> an Object::SafeEquals() method which compares uncompressed values
> and thus is safe to be used for comparing Code with non-Code objects.
>
> Bug: v8:11880
> Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82611}

Bug: v8:11880
Change-Id: Ie34af0135625eff2975f78f4d2901a76b8517eb7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842930
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82616}

This CL shuffles around some code in `ScopeIterator` to better reflect
the two (internal) iteration modes:

  - While "inside" the paused function we iterate based on lexical
    scopes.
  - Once we move past the paused function we iterate based on runtime
    contexts.

This CL renames the advancing functions to `AdvanceScope` and
`AdvanceContext` respectively which operate in the following way:

  - `AdvanceScope` first checks if the current lexical scope requires
    a context. If so, we move one context up the chain, since the next
    lexical scope belongs to that next context. Then we move up one
    lexical scope.

  - `AdvanceContext` moves one context up the context chain. Then we
    we move up through all the lexical scopes until we find the next
    lexical scope that requires a context.

The tricky bit is the transition from scope iteration mode to context
iteration mode. This is where the bug fix comes in. After doing one
standard `AdvanceScope` from the `closure_scope_` to the next
lexical scope, we need to keep moving up through the lexical scope
until we find the next lexical scope that requires a context.

The CL also changes how we collect the locals blocklist. The
locals blocklist is always put on the current context. So every
time we move up one context we reset the locals blocklist and
every time we move up the lexical scope we collect the scope
locals into the blocklist.


R=bmeurer@chromium.org, jarin@chromium.org

Fixed: chromium:1354464
Change-Id: I7b37687a8827c20d0660a25413d2c9117b5fe5ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842158
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82615}

AdvanceWithDeadline() was only used from AdvanceFromTask(). So we can
move this method into AdvanceFromTask().

AdvanceFromTask() and AdvanceOnAllocation() share quite some code,
there is already a common bottleneck for both methods: Step(). So we
can move that code into Step().

Bug: v8:12775
Change-Id: I0f749f52df05d951f4310f05ff0d3977c6b2a9aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843143
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82614}

Bug: v8:13052
Change-Id: I97c8d44dfd54d2a1352ceed7675d019bdec33396
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822863Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#82613}

The generational write-barrier currently does not support background threads. As a result, building in the background a ConsString that
points to a young string can lead to bugs, since the young string could
be freed.

Bug: v8:13203
Change-Id: I0df7c8cca8712d765eff0b1e918379f5477fdee5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840940Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82612}

When external code space is enabled comparing Code and non-Code objects
by looking at compressed values is not always correct. Such an approach
works only for comparing Code vs Code objects or non-Code vs non-Code
objects.

This CL instroduces SLOW_DCHECK into Object comparison operators to
ensure that such a comparison is allowed. Also, this CL instroduces
an Object::SafeEquals() method which compares uncompressed values
and thus is safe to be used for comparing Code with non-Code objects.

Bug: v8:11880
Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82611}

...to clear the recompilable code.

Bug: v8:13181
Change-Id: I6b78bbd2f08242fdd4659113ce1b4fa81174f8a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829243Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82610}

Write barrier was only used in Factory::CopyCode for the
InterpreterEntryTrampolineForProfiling. This was removed in
in https://crrev.com/c/3811287.

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

Bug: v8:13185
Change-Id: Id145e76ad52469d9aa8a12c9172851b086421afd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840217
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82608}

Turns out parking the outer Isolate needs to encompass the entire
lifetime of the inner Isolate during snapshot stress. Isolate
initialization locks the shared Isolate's client mutex to prevent shared
GCs. This mutex is also taken on Heap teardown on Isolate shutdown
during the shared heap verification, which may end up waiting in a
safepoint, causing deadlock.

Bug: v8:13217
Change-Id: I3893ae883ab345a9d36c9437ea15e90f18951057
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843288Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82607}

Bug: v8:12781
Change-Id: I0271c632a057ed457af5af59cb918d86472563d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827131
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82606}

Change-Id: I28747c49422280a7fd02ce771bd4f7c6ec60002c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840820
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82605}

Change-Id: I5da6270dc5c3d9b561eeb6c6dd3a938e705039c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843088Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82604}

This reverts commit abd0adf1.

Reason for revert: Test times out on Win64
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/23024/overview

Original change's description:
> [compiler] Make ReduceWord32EqualForConstantRhs work for Word64Equal
>
> Adds reduction case in MachineOperatorReducer for when the left-hand side of a
> Word64Equals is based on a 64-bit shift-and-mask operation, as is the case
> when Torque accesses 64-bit bitfields.
>
> This improves Speedometer2 by 0.15% on a Neoverse-N1 machine, with
> React-Redux being improved by 0.4%.
>
> Change-Id: Icd0451c00c1b25f7d370e81bddcfd668a5b2523c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834027
> Commit-Queue: George Wort <george.wort@arm.com>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82593}

Change-Id: I26515348a3d8de58445ecddc0486d9fcc2711cec
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3839048
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82603}

The mutex is there to protect against concurrent compilation of the same
function. It can be avoided by accumulating the vector of call targets
locally in the LiftoffCompiler, and only transferring it to the stored
type feedback once at the end (under the mutex).

Also, choose slightly better data structures: base::OwnedVector uses
less memory that std::vector (because it never over-reserves), and
std::unordered_map is more memory efficient and faster to lookup that
{std::map}.

R=jkummerow@chromium.org

Bug: v8:13209
Change-Id: I7aa82560a83cbac5c019effc7fd38c9b1495a42c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840294
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82602}

WaiterQueueNodes as used by JS synchronization primitives are per-main
thread, and external pointer handles to those nodes are 1-1. That
1-1-ness is captured by each main thread Isolate having a
waiter_queue_node_external_pointer_ field.

The current logic is incorrect on unlock paths as the Isolate that
requested the unlock can point its own
waiter_queue_node_external_pointer_ to another Isolate's
WaiterQueueNode. This CL fixes this by having each WaiterQueueNode hold onto its own external pointer handle.

This CL also fixes an embarrassing bug where the WaiterQueueNode was not correctly dequeued on timeout.

Bug: v8:13189, v8:12547
Change-Id: I8db16ae6d653d2e71989ad003faae20fcee06a25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3832298
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82601}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/339f8c6..8291582

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/3d64821..3a4c850

Rolling v8/buildtools/third_party/libc++/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxx/+log/6cc58d6..db72216

Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxab/+log/039323b..d2e4dc7

Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/030b4eb..f87795e

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapul/+log/b342107..7294631

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/268d645..44b7330

Rolling v8/third_party/fuchsia-sdk/sdk: version:9.20220812.1.1..version:9.20220819.1.1

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

Change-Id: I9fb7df0fc77ec27a1a8ea69eef080e095c22edf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842152
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82600}

Bug: v8:12548
Change-Id: Ib0b22cd941f0ab928c9c3d31d77695972d87c137
No-try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840817Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82599}

Bug: v8:12609, v8:12284
Change-Id: I2b72b20b64d3487343212f30fba614a92845e770
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3837854
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82598}

Otherwise allocated external pointer handles may be swept if never set
by the caller.

Bug: v8:10391
Change-Id: I3d727b80635ac8e21bd403de6bcad59091ed80a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3832528Reviewed-by: Samuel Groß <saelo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82597}

Currently there is nothing ensuring the internal VM state of shared
objects are in a coherent state and visible to other threads when the
shared object is published.

This CL adds a store-store memory barrier when returning from Factory methods that allocate shared JSObjects that are exposed to user JS code. For primitives, there is an additional store-store memory barrier in the shared value barrier.

Bug: v8:12547
Change-Id: I4833c7ebf02cc352da9b006d2732669d6d043172
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng,v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819041
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82596}

This CL makes concurrent MinorMC only bailout on the write barrier if
the value is not in young generation.

Bug: v8:13012
Change-Id: I941c6f1e676440cf69e1d4fefcf2786383c9f678
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840296
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82595}

Bug: v8:13206
Change-Id: I27cd34a77e15e812881a57e7e5538a0e31b34315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3837861Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82594}

Adds reduction case in MachineOperatorReducer for when the left-hand side of a
Word64Equals is based on a 64-bit shift-and-mask operation, as is the case
when Torque accesses 64-bit bitfields.

This improves Speedometer2 by 0.15% on a Neoverse-N1 machine, with
React-Redux being improved by 0.4%.

Change-Id: Icd0451c00c1b25f7d370e81bddcfd668a5b2523c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834027
Commit-Queue: George Wort <george.wort@arm.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82593}

Before https://crrev.com/c/3829541, ReduceStringPrototypeStartsWith
would not be called if the String's content wasn't safe to access in
the background, because StringRef::length would fail in that case. Now
that StringRef::length always succeeds, an additional check is
required before calling ReduceStringPrototypeStartsWith.

Note that none of the other callers of StringRef::length access the
String's content later, so we shouldn't have any more bugs caused by
the aforementioned CL.

Bug: chromium:1354439
Change-Id: I4a590ccdb7cc4c8a85e4e6beaf6f3c3ab2d7d479
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840938
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82592}

While working through the type feedback implementation, I left some
documentation and fixed some oddities or inconsistencies.

R=jkummerow@chromium.org

Bug: v8:13209
Change-Id: I6ba9b77ecf30ae020a57f77435005a1a57c2fc7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840293Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82591}

This CL bails out on the generated code write barrier when minor
incremental marking is active.

Currently is_minor_marking_flag_ is always false. It will be connected with incremental marking in subsequent CLs.

Bug: v8:13012
Change-Id: I0f5bc4aa14e9d56adbdad305499f2ca8f951765b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838784Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82590}

Bug: v8:12887
Change-Id: I467335899d8f4d72f256843d5922703d3ba1f976
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840936
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Liu Yu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#82589}

This reverts commit b3a27f22.

Reason for revert: Fails 'debug-enabled-tier-down-wasm' flakily (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64/48026/overview)

Original change's description:
> Reland "[wasm] Refactor compilation tier computations"
>
> This is a reland of commit e50472d6.
> In {ApplyCompilationHintToInitialProgress} we would reset the baseline
> tier to {kNone} if the compilation strategy is {kDefault}, which is
> wrong. We would not generate code but also not install the lazy stub,
> so whenever we start executing the code before top-tier is ready we
> would crash.
>
> Original change's description:
> > [wasm] Refactor compilation tier computations
> >
> > The way we initialized the "compilation progress" was pretty convoluted,
> > with multiple levels of functions being called for initializing every
> > single slot.
> >
> > This CL refactors this to compute one default value for the whole
> > module, and only modifies those slots that need special handling (e.g.
> > because of compilation hints, or lazy/eager compilation after
> > deserialization).
> >
> > We also rename "liftoff_functions" to "eager_functions" in the
> > deserialization path; the idea is that those functions should get
> > eagerly compiled because we expect them to be needed during execution.
> > Usually they would be Liftoff-compiled, but it's more consistent to use
> > the existing logic to choose the baseline tier. In the default
> > configuration, this will still use Liftoff, but if Liftoff is disabled
> > we will use TurboFan instead.
> >
> > R=jkummerow@chromium.org, ahaas@chromium.org
> >
> > Bug: v8:12425
> > Change-Id: Ie58840b19efd0b1e98f1b02d5f1d4369410ed8e1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829606
> > Commit-Queue: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#82521}
>
> Bug: v8:12425
> Change-Id: Ie41e63148bf6bd0e38fc07a3a514f1094d9d26cf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838409
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82585}

Bug: v8:12425
Change-Id: Ic86d3f5b0e0603dae62ccead3be052d928209506
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842208
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82588}

Now that V8_SANDBOXED_POINTERS is enabled by default on every platform
if the sandbox is enabled, it is no longer necessary to have a separate
option to enable/disable sandboxed pointers.

Bug: chromium:1218005
Change-Id: I2ab4c7c758010007765a3b0595357ddecfe9f258
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840937Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82587}

Since the overall motionmark regression is minor (<0.5%), we decided to
get benefits of pointer compression on M1. The CL can also slightly
regress speedometer2 (~0.3%).

Bug: chromium:1325007
Change-Id: Ib278f0e82e0ebde563caac79b9f32edfe2d09a53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840301
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82586}

This is a reland of commit e50472d6.
In {ApplyCompilationHintToInitialProgress} we would reset the baseline
tier to {kNone} if the compilation strategy is {kDefault}, which is
wrong. We would not generate code but also not install the lazy stub,
so whenever we start executing the code before top-tier is ready we
would crash.

Original change's description:
> [wasm] Refactor compilation tier computations
>
> The way we initialized the "compilation progress" was pretty convoluted,
> with multiple levels of functions being called for initializing every
> single slot.
>
> This CL refactors this to compute one default value for the whole
> module, and only modifies those slots that need special handling (e.g.
> because of compilation hints, or lazy/eager compilation after
> deserialization).
>
> We also rename "liftoff_functions" to "eager_functions" in the
> deserialization path; the idea is that those functions should get
> eagerly compiled because we expect them to be needed during execution.
> Usually they would be Liftoff-compiled, but it's more consistent to use
> the existing logic to choose the baseline tier. In the default
> configuration, this will still use Liftoff, but if Liftoff is disabled
> we will use TurboFan instead.
>
> R=jkummerow@chromium.org, ahaas@chromium.org
>
> Bug: v8:12425
> Change-Id: Ie58840b19efd0b1e98f1b02d5f1d4369410ed8e1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829606
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82521}

Bug: v8:12425
Change-Id: Ie41e63148bf6bd0e38fc07a3a514f1094d9d26cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838409Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82585}

NormalPageMemoryRegion is a span of 10 pages, all of which must belong
to the same space. This requirement imposes a fragmentation issue for virtual space, which is not ideal for the current 2GB cage
configuration.

The CL fixes this by mixing pages of different spaces inside the same
NormalPageMemoryRegion. With cage it's actually not necessary anymore
to have NormalPageMemoryRegion, but we keep it to allow the code to be
uniform for cage/non-cage configurations.

There is no type confusion across spaces, since pages (even empty) are
never shared between spaces. In addition, the shared cage puts an
additional memory constraint on the GC. So, there is no security benefit
in having NormalPageMemoryRegion assigned to a single space.

Savings in reserved address space:
cnn:2021: 14%
facebook_infinite_scroll:2018: 23%

Bug: chromium:1325007, chromium:1352649
Change-Id: I7b49032d581dd56feb8633734a1f37803e9526c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840749Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82584}

The function is no longer used in Chromium or V8 and can therefore be
deleted. This CL also simplifies V8::GetSandboxSizeInBytes, which now no
longer needs to be able to deal with an uninitialized sandbox.

Bug: v8:10391
Change-Id: I22d6b0e03de1fd2ba3d38c4e476fca44068b62f9
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769690Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82583}

Bug: v8:13089
Change-Id: Ic1c5a596adb822494aff490e04bd23cf84fb53f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840295
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82582}

This CL removes the COMPLETE state from incremental marking. Since
then the only states left were STOPPED and MARKING, we can replace
the state with an is_running_ boolean field.

The state could change back-and-forth between MARKING and COMPLETE.
IsMarking() was already also checking for COMPLETE. So most code
already treated both states the same. IsComplete() now checks whether
marking is running and a transitive closure was reached already.

IncrementalMarking::Step() didn't process the marking queue when in
COMPLETE. This should be relatively rare though since it only
transitioned into COMPLETE when the stack guard was armed and the
allocation observer ran again before reaching a stack guard check.

Bug: v8:12775
Change-Id: Ied48d8c512ad3d1b3d2e29393d43b434b5fda8fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3835689Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82581}

This reverts commit c3a5c5b1.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20shared/21941/overview

Original change's description:
> [heap] Ensure all old-to-shared slots are recorded
>
> This CL adds verification of the old-to-shared remembered set to
> --verify-heap. During shared GCs client heaps will be scanned for
> references into the shared heap, this CL will CHECK that every found
> slot is contained in the old-to-shared remembered set. After this
> gets a bit more stable, the full heap iteration can be dropped and we
> can fully rely on the remembered set instead.
>
> Bug: v8:11708
> Change-Id: I0b5c4edfe3271306e4e7af7394472534113e1953
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792605
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82578}

Bug: v8:11708
Change-Id: I26553d3b06d0e257a3425eeb884ccce57f026bde
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3841567
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82580}

`JSWasmCallData` is replaced with a flag `do_conversion` to indicate if conversions of arguments and returns are needed, which is set as false for inlined js-to-wasm call wrappers.

Bug: v8:9407
Change-Id: I35244c8fc13d464d48031fb9d7d04ab277646ec5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3837858Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82579}

This CL adds verification of the old-to-shared remembered set to
--verify-heap. During shared GCs client heaps will be scanned for
references into the shared heap, this CL will CHECK that every found
slot is contained in the old-to-shared remembered set. After this
gets a bit more stable, the full heap iteration can be dropped and we
can fully rely on the remembered set instead.

Bug: v8:11708
Change-Id: I0b5c4edfe3271306e4e7af7394472534113e1953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792605Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82578}

This is a reland of commit 776b9eb9

Original change's description:
> [WATCHLISTS] Add riscv watch
>
> Change-Id: I6e4dc69d6f22d3108ae74552b72bcafc0be3db64
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793476
> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82092}

Change-Id: I33ff1808de80f03fdfd7c977b29a895c8110bae0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3835293Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#82577}