Also add AOs:
ParseTemporalRelativeToString, DefaultTemporalLargestUnit, CalculateOffsetShift, UnbalanceDurationRelative, BalanceDurationRelative,


Spec Text:
https://tc39.es/proposal-temporal/#sec-temporal.duration.compare
https://tc39.es/proposal-temporal/#sec-temporal.duration.prototype.round
https://tc39.es/proposal-temporal/#sec-temporal.duration.prototype.total
https://tc39.es/proposal-temporal/#sec-temporal-parsetemporalrelativetostring
https://tc39.es/proposal-temporal/#sec-temporal-defaulttemporallargestunit
https://tc39.es/proposal-temporal/#sec-temporal-calculateoffsetshift
https://tc39.es/proposal-temporal/#sec-temporal-unbalancedurationrelative
https://tc39.es/proposal-temporal/#sec-temporal-balancedurationrelative

Bug: v8:11544
Change-Id: I3b20bdb7cec30f6a8503603169643678988f4dcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3750322
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81942}

Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
with which an embedder could request that V8 merge newly deserialized
script data into an existing Script from the Isolate's compilation
cache. This change implements those new functions. This functionality is
still disabled by default due to the flag
merge_background_deserialized_script_with_compilation_cache.

The goal of this new functionality is to reduce memory usage when
multiple frames load the same script with a long delay between (long
enough for the script to have been evicted from Blink's in-memory cache
and for the top-level SharedFunctionInfo to be flushed). In that case,
there are two Script objects for the same script: one which was found in
the Isolate compilation cache (the "old" script), and one which was
recently deserialized (the "new" script). The new script's object graph
is essentially standalone: it may point to internalized strings and
readonly objects such as the empty feedback metadata, but otherwise
it is unconnected to the rest of the heap. The merging logic takes any
useful data from the new script's object graph and attaches it into the
old script's object graph, so that the new Script object and any other
duplicated objects can be discarded. More specifically:

1. If the new Script has a SharedFunctionInfo for a particular function
   literal, and the old Script does not, then the old Script is updated
   to refer to the new SharedFunctionInfo.
2. If the new Script has a compiled SharedFunctionInfo for a particular
   function literal, and the old Script has an uncompiled
   SharedFunctionInfo, then the old SharedFunctionInfo is updated to
   point to the function_data and feedback_metadata from the new
   SharedFunctionInfo.
3. If any used object from the new object graph points to a
   SharedFunctionInfo, where the old object graph contains a matching
   SharedFunctionInfo for the same function literal, then that pointer
   is updated to point to the old SharedFunctionInfo.

The document at [0] includes diagrams showing an example merge on a very
small script.

Steps 1 and 2 above are pretty simple, but step 3 requires walking a
possibly large set of objects, so this new API lets the embedder run
step 3 from a background thread. Steps 1 and 2 are performed later, on
the main thread.

The next important question is: in what ways can the old script's object
graph be modified during the background execution of step 3, or during
the time after step 3 but before steps 1 and 2?

A. SharedFunctionInfos can go from compiled to uncompiled due to
   flushing. This is okay; the worst outcome is that the function would
   need to be compiled again later. Such a risk is already present,
   since V8 doesn't keep IsCompiledScopes for every compiled function in
   a background-deserialized script.
B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
   compilation. This is also okay; the merge completion logic on the
   main thread will just keep this lazily compiled data rather than
   inserting compiled data from the newly deserialized object graph.
C. SharedFunctionInfos can be cleared from the Script's weak array if
   they are no longer referenced. This is mostly okay, because any
   SharedFunctionInfo that is needed by the background merge is strongly
   referenced and therefore can't be cleared. The only problem arises if
   the top-level SharedFunctionInfo gets cleared, so the merge task must
   deliberately keep a reference to that one.
D. SharedFunctionInfos can be created if they are needed due to lazy
   compilation of a parent function. This change is somewhat troublesome
   because it invalidates the background thread's work and requires a
   re-traversal on the main thread to update any pointers that should
   point to this lazily compiled SharedFunctionInfo.

At a high level, this change implements three previously unimplemented
functions in BackgroundDeserializeTask (in compiler.cc) and updates one:

- BackgroundDeserializeTask::SourceTextAvailable, run on the main
  thread, checks whether there is a matching Script in the Isolate
  compilation cache which doesn't already have a top-level
  SharedFunctionInfo. If so, it saves that Script in a persistent
  handle.
- BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
  whether the persistent handle from the first step exists (a fast
  operation which can be called from any thread).
- BackgroundDeserializeTask::MergeWithExistingScript, run on a
  background thread, performs step 3 of the merge described above and
  generates lists of persistent data describing how the main thread can
  complete the merge.
- BackgroundDeserializeTask::Finish is updated to perform the merge
  steps 1 and 2 listed above, as well as a possible re-traversal of the
  graph if required due to newly created SharedFunctionInfos in the old
  Script.

The merge logic has nothing to do with deserialization, and indeed I
hope to reuse it for background compilation tasks as well, so it is all
contained within a new class BackgroundMergeTask (in compiler.h,cc). It
uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
the object visitation that updates pointers to SharedFunctionInfos.

[0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit

Bug: v8:12808
Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81941}

No-Try: true
Bug: v8:13107
Change-Id: I18ed93605594c7d2baba6fb744439df0eb4cb3ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785146
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81940}

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

Bug: v8:10470
Change-Id: I67e1962c17caecdf7cd9e8ac64ce7e4c0d694a21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776693Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81938}

... api/api-wasm-unittest.

Bug: v8:12781
Change-Id: I6d6eafcbc67e114fc1fa9b1f1f8dea21ab831ee6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3748165Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#81937}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/be25fb2..d580717

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/a4506d5..af18ab7

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0ca99b7..3d8d88e

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

Change-Id: Idfaaa0c7c941d19b623af4f69db6b67a051f9a1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785204
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81936}

Bug: v8:13101
Change-Id: I1fbcfd5758e3fb739b79c7d381e62b380cd14a2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784227Reviewed-by: Liviu Rau <liviurau@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81935}

Jump gap moves (for phis and register merges) are emitted as a parallel
move (i.e. treated as a single mapping from registers to registers and
emitted in a way that they don't clobber each other). However, the phi
input allocation was updating the register state as if they were
serialised moves (i.e. a list of moves, one after the other, where each
move could clobber another move's input).

Now the jump phi initialisation doesn't update register state.

Bug: v8:7700
Change-Id: Iecf3211d59d9c416a4449aea22fef633717d92d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784983Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81934}

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

It's not allowed to call CodeLookupResult::ToCodeT() from the middle
of GC.

Bug: v8:13100, v8:11880
Change-Id: Idd53794a9f881d01dbf0c372fbb698dbd8fecf94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785009Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81932}

This CL moves a few methods and nested class SlotSnapshottingVisitor
from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility.

Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter.

This is preparatory work for adding a
YoungGenerationConcurrentMarkingVisitor class, which will be able to
reuse members of ConcurrentMarkingVisitorUtility.

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

This reverts commit c3f18ae6.

Reason for revert: Speculative revert for https://luci-milo.appspot.com/ui/inv/build-8807661142690641489/test-results?q=conformance%2Fogles%2FGL%2FgreaterThanEqual%2FgreaterThanEqual_001_to_008.html

Original change's description:
> Reland "cppgc: Enable pointer compression by default on Desktop"
>
> - The data race on atomic memcpying/memsetting was fixed;
> - All the known alignment issues in Blink were fixed;
> - Several perf optimizations were applied.
>
> Original change's description:
> > cppgc: Enable pointer compression by default on Desktop
> >
> > The CL enables pointer compression in Oilpan.
> >
> > For sherrifs: the CL may cause some slight perf regressions (likely
> > blink_perf.*), due to slightly higher cost of compression and
> > decomrpession.
> >
> > Speedometer2 is not expected to regress, as was checked locally. Such a
> > slight performance degradation is compensated by memory savings that are
> > expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer
> > PMF).
>
> Bug: chromium:1325007
> Change-Id: I5fa9a06cb1fa5141f4e2b22e710007e2404a176b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762567
> Auto-Submit: Anton Bikineev <bikineev@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81914}

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

This reverts commit 60e9b503.

Reason for revert: Speculative revert for https://luci-milo.appspot.com/ui/inv/build-8807661142690641489/test-results?q=conformance%2Fogles%2FGL%2FgreaterThanEqual%2FgreaterThanEqual_001_to_008.html

Original change's description:
> cppgc: Consistently treat sentinel pointer as live
>
> Sentinel pointers would be treated as live by the GC (through
> `HandleWeak()` but would be treated as dead when checked explicitly
> through the `LivenessBroker` in e.g. custom callbacks.
>
> Treat sentinel pointers as live consistently across all callsites
> and weak types.
>
> Change-Id: I9a4c096ddac1a111df808f3683325b55e7597eea
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782800
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81916}

Change-Id: Ic1ea0655499ae2e4ae7252fda7158d809e4970ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783992
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
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@{#81929}

... objects/weaksets-unittest.

Bug: v8:12781
Change-Id: I355deaff33e4bfe7125af587654cae39f2d719d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784616Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#81928}

We update RegisterMerge information for DoubleRegister, but don't
actually emit the gap moves for them. This required templatifying some
more code on the register type, and exposing a general LoadToRegister
for ValueNode.

Bug: v8:7700
Change-Id: I7122b5c562bab20d8f912936ff150d15b9cc033f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785003
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81927}

Too often, maglev has an issue during graph building. These are hard to
debug, because failing to build a graph means that no graph can be
printed. This patch adds a tracing printer that dumps out nodes as they
are added to the graph -- it doesn't have the beautiful unicode arrows,
but at least it's something.

Bug: v8:7700
Change-Id: Id6673a9ee2436eac365d6d449dd2fa49bdc354d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780527Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81926}

a.k.a. "option 1a". Reflects the resolution of this discussion:
https://github.com/WebAssembly/function-references/issues/44

Bug: v8:7748
Change-Id: I6b53c353a1ace2aaf5b852addead51b9f76c9d64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782674Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81925}

Bug: v8:10391
Change-Id: I6075a8fe3c201f9221149e0c54edf4fb191088da
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/+/3757342
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81924}

The new method is not implemented in Chrome or Node, and the issue has
no activity since 2018, so let's rip out the incomplete new API.

Drive-by: Sprinke a few V8_LIKELY and V8_UNLIKELY.

R=mlippautz@chromium.org

Bug: chromium:634547
Change-Id: I0dabad520d459277d7196fa69c1bbceaf4d53596
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780528Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81923}

... including LogMapsCodeTest.LogMapsDetailsCode, LogMapsTest.LogMapsDetailsStartup
and LogMapsTest.LogMapsDetailsContexts.

Bug: v8:12997
Change-Id: I9dc315d7361efb8c58bf7ad3be8e324cdd456184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784617Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#81922}

Bug: v8:7700
Change-Id: Ibd40e7bf3f0681f358bb2ed0785fce9a50f8b617
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784599Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81921}

Sometimes the second Wasm instantiation fails because we run out of
memory. This raises a RangeError, which is not recognized by ClusterFuzz
as OOM.
Thus turn it into a proper OOM crash.

R=ahaas@chromium.org

Bug: chromium:1347024
Change-Id: I39f7789cc85a9ba9b4217764fbbcef15c6c6ed76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784602Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81920}

Whenever PagedNewSpace allocates a page, the page is added to the free
list. Preallocating pages on space initialization means the pages are
added to the free list before the map for free space is initialized.
Then, when allocating from the free list, a DCHECK fails
(free-list.cc:508).

This CL delays page preallocation until `EnsureCurrentCapacity` is
called. When using PagedNewSpace, we will call this method from
`Heap::CreateHeapObjects` after the maps are allocated and before any
allocations in new space are attempted.

Bug: v8:12612
Change-Id: I33f825ddd831640b12e4c0f7b849262a335df51e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780541Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81919}

Bug: v8:13101
Change-Id: I5d144939b420957eab58ead64836b561bd541a00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784601
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81918}

Bug: v8:7700
Change-Id: Ib3325ff8f764f7a3bd6c064a5ad301c384503d99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784594
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81917}

Sentinel pointers would be treated as live by the GC (through
`HandleWeak()` but would be treated as dead when checked explicitly
through the `LivenessBroker` in e.g. custom callbacks.

Treat sentinel pointers as live consistently across all callsites
and weak types.

Change-Id: I9a4c096ddac1a111df808f3683325b55e7597eea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782800
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81916}

With this CL the time is measured from when the streaming decoder is
finished until the time when the compilation of all functions of the
streamed module is finished. If the streaming decoder finishes second,
the time gets recorded negatively. This timer should allow us eventually
to check whether the assumption that Liftoff compilation is faster than
downloading module bytes is correct.

R=clemensb@chromium.org

Bug: v8:12924
Change-Id: I2b7fbdef891d1eda77706ffbd20cf223b91b901c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3678839
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81915}

- The data race on atomic memcpying/memsetting was fixed;
- All the known alignment issues in Blink were fixed;
- Several perf optimizations were applied.

Original change's description:
> cppgc: Enable pointer compression by default on Desktop
>
> The CL enables pointer compression in Oilpan.
>
> For sherrifs: the CL may cause some slight perf regressions (likely
> blink_perf.*), due to slightly higher cost of compression and
> decomrpession.
>
> Speedometer2 is not expected to regress, as was checked locally. Such a
> slight performance degradation is compensated by memory savings that are
> expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer
> PMF).

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

Due to top-byte ignore (TBI) in Arm64, only bits [48, 56) can be used
for type tags as otherwise type-check failures may go unnoticed if they
only leave bits in the top byte set. This CL therefore switches the
external pointer tagging scheme to use 8-bit tags.

Bug: v8:10391
Change-Id: Ia1f379ebc1bbda4117785d2dc119bc8dfa358711
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/+/3776688
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81913}

The return value of StringBuilder::cursor() isn't safe to store across
print operations, because it will become stale if the StringBuilder
needs to grow its buffer. The solution is to store the length() instead,
and recompute the raw pointer from the updated start() when needed.

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

This CL fixes two lock-order-inversion warning in the DefaultPlatform.
The problem was that during shutdown locks get taken in the oposite
order than during initialization.

The first two conflicting locks were the WasmEngine lock and the
lock of the DefaultTaskRunner. During WasmEngine initialization, when
the WasmEngine lock is hold, a foreground task is scheduled, which
requires the TaskRunner lock. During shutdown, the task queue of the
TaskRunner gets drained while holding the TaskRunner lock. Thereby
the destructors of the tasks get executed, and the LogCode task of
the WasmEngine thereby acquires the WasmEngine lock.

The second conflict happens between the WasmEngine lock and the
DefaultPlatform lock, where the DefaultPlatform lock is taken during
WasmEngine initialization when the ForegroundTaskrunner is acquired.
During Shutdown, the DefaultPlatform lock was hold while the task
queue was drained, as described above.

Bug: chromium:1346250
Change-Id: Ib67d0c6cad1372e7c592f40bbe68b0ae31b2976b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782796
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81911}

All embedders override this method now, so it can be abstract.

R=mlippautz@chromium.org

Bug: v8:12425
Change-Id: I4db5d74341c9519222592a88d247bc2aa2be03a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780538Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81910}

This allows to run a test repeatedly (in the same process) which
always sets the flag(s) to the same value. This also applies to
fuzzers.

The {FlagValue<T>::operator=} is the central bottleneck which is now
used for any flag value updates, either via the FLAG_foo globals, or
via the internal or public API.

R=cbruni@chromium.org

Bug: v8:12887, chromium:1346284
Change-Id: I46662322e1420ee12314544302ad9700523dcf90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780525
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81909}

This is a follow up to Iadf73c294904ec20cefe1053a2969aa1dbb91a39.

Bug: v8:7748
Change-Id: I59390b8c82c4ebed58f2d3130cd9b1578bffdd4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780535
Commit-Queue: Matthias Liedtke <mliedtke@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@google.com>
Cr-Commit-Position: refs/heads/main@{#81908}

Manually roll forward `google_benchmark` and rely on the shipped
export header file. Adjust the build rules to always imply a static
build though as that's how the library is used in v8.

Bug: chromium:1346538
Change-Id: Ia94ad976f533a1c1d8099f1bc931b491d6fb17dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782798Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81907}

This CL changes `scheduleTask` to use a cached ObjectTemplate to
create the JS task objects. Console creates the template lazily upon
first use.

A local micro benchmark that creates 100k task objects shows a
speedup of roughly 4x.

R=jarin@chromium.org

Bug: chromium:1334585
Change-Id: Ice037ad32836fe428b1bcbee15738cb17877a3dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779496
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81906}

Minor cleanup CL for better readability.

R=kimanh@chromium.org

Bug: chromium:1334585
Change-Id: I430a33e2b7173e146ff9927e70b06a04770cd956
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779495Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81905}

Rolling v8/buildtools/third_party/libc++/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxx/+log/ae6c9d1..476d5ae

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

Change-Id: I426c18c1fe0c61b19d9ad39144c6243016c0cec1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783912
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81904}

A couple of allocation were still going to new space. Since objects
allocated during isolate initialization are long living anyway, we
should pretenure them.

This also untangles preallocating pages in the paged new space.

Bug: v8:12612
Change-Id: Ib63ff4445930afa5969464e6adaef85b314e95ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782802Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81903}