... and prepare for using PGO profiles for arm builds.
Bug: v8:10470
Change-Id: If71d363195c60277a59dc68d0c18e361e24209c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3970665
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83867}
The feature has been enabled since M106 so we can safely remove the
flag with M109.
R=bmeurer@chromium.org
Bug: chromium:1334585
Change-Id: Iefe0b10e3be59d6dde54d676b5f1e0cf938851ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3959659
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83865}
Fix by disabling the use of the trap handler in the "ARM64 simulator
running on x64" case. (Note that the ARM64-simulator-on-x64 case gets
built for mksnapshot as a host tool even if we didn't specifically
want the simulator case.)
Using the trap handler in that case currently uses some inline
assembly (the top-level asm() statements in
src/trap-handler/handler-outside-simulator.cc), but MSVC does not
support that type of asm() statement.
Disable using that asm() code by conditionalising it on "#if
V8_TRAP_HANDLER_SUPPORTED". Note that we're not putting this
condition into the GN build because it's complicated to keep the two
sets of conditions totally in sync.
Put the "#if V8_TRAP_HANDLER_SUPPORTED" into handler-inside-win.cc to
match the same #if in handler-inside.cc, otherwise we would get a link
error when the former refers to TryFindLandingPad(), which is defined
behind the #if in the latter.
Do the same in handler-inside-posix.cc for consistency.
Remove the earlier attempt at doing the fix by implementing
ProbeMemory in C++, which won't necessarily work. This reverts:
https://chromium-review.googlesource.com/c/v8/v8/+/3913036
Change-Id: If8e1720a90f89175d730cf32ee5ac42451b9b5be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3964232
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Mark Seaborn <mseaborn@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83864}
It's been enabled by default since Chrome 91.
Bug: v8:6020
Change-Id: Id26b7fb0b7dffe19a88a6f0071dd59203b06415a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3957636
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83862}
Port a02c56694f
Original Commit Message:
This is a reland of commit 4804c4de31.
There are major changes since the previous attempt:
- The WasmLiftoffFrameSetup (formerly WasmGetFeedbackVector) builtin
now performs as much of the frame setup work as possible, to reduce
generated code size for each function.
- The WasmLazyCompile builtin/runtime function no longer allocates,
hence gets frame type INTERNAL, and is un-handlified.
Original change's description:
> [wasm] Allocate feedback vectors on demand
>
> We previously allocated feedback vectors when instantiating the module,
> or when lazily compiling a function. That's not sufficient when there
> are multiple instances of the same NativeModule, or when we eagerly
> tier-down all code for debugging. This patch changes the "get vector from
> instance" sequence at the beginning of every Liftoff function to "get
> or allocate vector"; factored into a builtin call to avoid generating
> more code for every function.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939667
> Cr-Commit-Position: refs/heads/main@{#83610}
R=jkummerow@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I7d7e65a32e89285cb583216455ea1b9a490cb16b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968705
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83861}
We pass the *declared* function index on the stack now, so we must
convert it to a regular function index before using it to look up
the function's signature.
Change-Id: Ib98d71a02ba8ca885136c010cf7dbb6ef7f62950
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3971365
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83860}
This enriches KnownNodeAspects to use a map from Node to a set of
Maps, instead of a single map. We update known maps with set
intersection. We recompute the set from scratch, since set removal
is expensive.
It also adapts CheckMaps and CheckMapsWithTransition to support
a set of maps.
Bug: v8:7700
Change-Id: I0c16a456a1a186aaedcbacf2491ec4f0cb8b0682
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3966441
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83859}
Similar to how `time COMMAND` measures time, `rss.py COMMAND` measures
memory consumption, by sampling RSS (Resident Set Size) for the child
process in /proc at a configurable interval (default: every 1ms).
No-Try: true
Change-Id: I381cdd6325fae67944ee96e44ba09dd948d432cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3971360
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83858}
Make maglev less aggressive, and TF a little more again. Maglev deopts
will ensure that we'll back off on TF as long as feedback changes.
Bug: v8:7700
Change-Id: I98b4c339de598d96329b79d7b6862605f9bfd87c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968703
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83856}
PagedSpaceIterator just bailed out on first optional space.
Bug: v8:13267
Change-Id: I6f8dba6c510a641930b364698dc91529b2db1146
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3971361
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83855}
%OptimizeFunctionOnNextCall could be called while compilation (Maglev or
Turbofan) was still on-going -- this would make DCHECKs fail when
attempting to save the compiled code on the feedback vector. This is not
an issue normally when tests are carefully crafted, but can easily
happen during fuzzing.
Unify the two %Optimize*OnNextCall paths, and make sure that they check
for in-progress compilation.
Fixed: v8:13404
Change-Id: I021e1305bc2ba769b7484f9a122792aeb22060ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3971122
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83854}
Code coverage tests invoke garbage collection, to test that coverage
data is not reclaimed by the garbage collector and that the native
%DebugTogglePreciseCoverage works as intended. One of them tests that
garbage collection indeed reclaims the coverage data, if the above
native is not used. When conservative stack scanning is used, this may
fail.
This CL fixes the tests, ensuring that a precise garbage collection
will be invoked, without scanning the stack. To achieve this, the
garbage collection is invoked not with %CollectGarbage but by using
--expose-gc and the asynchronous execution mode, which ensures that
it will be invoked from the event loop without a stack.
Bug: v8:13257
Change-Id: Id44ef0d442bfd0a8afda282c3345e5ebeb239356
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968708
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83851}
This reverts commit 6e4dea75e8.
Reason for revert: This is blocking HEAD import in Copybara.
Let's test this there first, then backport the change.
Original change's description:
> [bazel] Add hide symbols from release / fast builds
>
>
> Our gn build files hide non-exported symbols by default, which results
> in smaller binaries and can improve build times.
>
> This was not ported to the bazel build and causes binary size
> regressions in google 3.
>
> Change-Id: I285914b83e75bd3bf406e6401f52ddb53230219a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925698
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83514}
Change-Id: I18561cfdd8a637c100be849c4d6a668c6f3b6080
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3971120
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83850}
For memory64, we modified the {consume_resizable_limits} method to
support 64-bit LEBs. This method is not only used for memory limits
though, and other limits should be unaffected (they are always 32-bit
values, even in memory64).
This CL refactors decoding such that the {has_maximum} fields are
initialized earlier, and flags are only decoded once (in particular not
again inside {consume_resizable_limits}. Instead, the caller specifies
whether values should be decoded as 32-bit or 64-bit values.
R=jkummerow@chromium.org
Bug: v8:10949, v8:13401
Change-Id: I2fb76c3efcf153d1490d88c4456de1524fd508b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968482
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83849}
This CL makes the object keeping stack information thread-local, moving
it from Heap to ThreadLocalTop. In this way, stack scanning will work
correctly when switching between threads, e.g., using v8::Locker.
It also introduces a mechanism for setting a stack marker, to be used
for scanning only the part of stack between its start and the marker
(instead of the current stack top).
Bug: v8:13257
Change-Id: I01091f5f49d9a8143d50aeef53789a98bdb29048
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3960991
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83848}
For some reason we overlooked shared memory64 so far. Supporting it is
trivial, we just need to fix flag parsing.
To make parsing simpler, we replace the switch by a bit-decoding logic.
R=jkummerow@chromium.org
Bug: v8:10949, v8:13401
Change-Id: I1d884a174f901ed359c1d385055c9f2d24b0e2f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3967904
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83846}
This adds a new [[WeakRefTarget]] internal property to
`Runtime.getProperties` results for `JSWeakRef` results
(also included in the preview), which will be used by
DevTools to show the target of the weak reference without
having to explicitly call `deref()` on them. As part of
this we also have (temporary) strong references to the
target, slightly changing behavior, but that's consistent
with how DevTools deals with `JSWeakMap` and `JSWeakSet`.
Bug: chromium:1267690
Change-Id: I2a9ef9261996fcdee20fbd0fc728d11208c82459
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3970598
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83844}
If the call target is a known constant, we don't need to check the value
stored in the feedback array dynamically. Either it matches, in which
case we just perform the call, or it's different, in which case we
unconditionally deopt so we can update the feedback.
Bug: v8:7700
Change-Id: Iacfdd9f358aac9c1d4e5cc748f323c3d90597d41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3971077
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83843}
A bit of restructuring to reduce branching on RememberedSetUpdatingMode.
Bug: v8:12612
Change-Id: Ia578b2045e13698d1545d16e5a0df75ee599e24d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3966190
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83842}
VerifyRememberedSetsAfterEvacuation DCHECKs that OLD_TO_SHARED
invalidated set is null. MinorMC does not filter OLD_TO_SHARED
remembered set and thus the DCHECK fails.
Bug: chromium:1376860
Change-Id: I0f17687b3c1bc74c3b1c4afa462c99de5a05f78c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968707
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83841}
When inlining a tail call node into a regular call, the tail call node
is transformed into a regular call. This new call node (or its
projections in the case of multi-return) has to be typed.
Bug: v8:13406, v8:12166
Change-Id: I39cc619e6ee4f0d16763699fe4facebe461a750f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968715
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83839}
Rolling v8/build: 8d71aab..35a1478
Rolling v8/buildtools: f45ca77..be63ea5
Rolling v8/buildtools/linux64: git_revision:57c352b2b03461c24b19c678c61d7aeacc6981f4..git_revision:27b90626701a112217a9244022c729231ebcc3a0
Rolling v8/buildtools/third_party/libc++/trunk: 9c5e35a..9f512cf
Rolling v8/buildtools/third_party/libc++abi/trunk: 685c4ad..519e9ef
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/62b4c4e..981585a
Rolling v8/third_party/depot_tools: bd0cea6..3b95525
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221019.3.1..version:10.20221020.1.1
Rolling v8/third_party/instrumented_libraries: 5104b7e..459048b
Rolling v8/third_party/zlib: 3cec057..cff7208
Rolling v8/tools/luci-go: git_revision:2673c9d7d4a38bce69415221fe721f807e909d85..git_revision:50ab33853a8b220162f851dcb74a1519e106b3df
Rolling v8/tools/luci-go: git_revision:2673c9d7d4a38bce69415221fe721f807e909d85..git_revision:50ab33853a8b220162f851dcb74a1519e106b3df
Change-Id: I8c10c836da728f400838364c8fc451b781c6f862
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968513
Bot-Commit: 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/main@{#83835}
This can certainly be optimized further, but we just check the value
inline rather than calling into Call_*WithFeedback
Bug: v8:7700
Change-Id: I19daf5eba86e1fb42e02e3e598135e5e9ff9dfd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3967842
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83833}
Add a sanity check and a note to ensure that use of V8's trap handler
is not naively enabled for Android without seeing this note.
Using the trap handler on Android is potentially risky because V8 may
have to coexist in the same process with Android's Java
implementation, which may also use signal handling, and getting
different signal handlers to coexist safely is quite difficult.
Bug: v8:13383
Change-Id: I5caa52577bf0c74635171adac0dcaed32295d654
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956130
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Seaborn <mseaborn@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83830}
We were setting the interrupt budget before performing Maglev tier-up,
therefore ignoring that tiering state and resetting the interrupt budget
to the tier-to-maglev budget, not the tier-to-turbofan budget. Now, set
the interrupt budget
a) only after the optimisation decision is made, and
b) based on tiering state as well as the active tier -- in particular,
any tiering state that isn't "none" is treated as needing the
tier-to-turbofan budget.
Bug: v8:7700
Change-Id: Ife353b32c580cac92c051eb40f58294069930786
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3968479
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83828}
Change-Id: I5760687fa9e8a7512d3946704f51f321ffa3676b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3963718
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83827}
... otherwise AllocateRaw can call the allocation builtin,
that can trigger a GC and read the character as a pointer.
Bug: v8:7700, v8:13397
Change-Id: If4e15fc8bfe0f94c53fe77022b18d5d4a6168702
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3964754
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83826}
When merging a newly deserialized script into an existing one from the
compilation cache, it is often the case that a SharedFunctionInfo from
the cached script ("old SFI") has been flushed and the corresponding
SharedFunctionInfo from the new script ("new SFI") is compiled. In that
case, it is sufficient to copy the bytecode array and feedback metadata
from the new SFI to the old SFI, as already implemented.
However, there is another case to consider: perhaps the new SFI is
compiled and the old SFI was never compiled. In that case, the old SFI
has no ScopeInfo and some of its flags may be incorrect.
To fix the problem, this CL updates CompleteMergeInForeground to copy
everything except script_or_debug_info from the new SFI to the old SFI.
This change implies some duplication of ScopeInfos, since each ScopeInfo
can point to its parent, so matching parent ScopeInfos from the new and
old scripts will coexist. However, this isn't a new problem: similar
duplication is already caused by the portion of the merge algorithm
which attaches new compiled SFIs into the old Script where the old
Script doesn't have a matching SFI. I don't see any way in which this
duplication would cause incorrect behavior. In fact, it is possible to
get duplicated ScopeInfos without any merging at all, which indicates to
me that such duplication is safe. Duplication occurs if a SFI is flushed
or removed while one of its descendant functions is still alive, and
subsequently the same function literal is compiled again.
Bug: v8:12808, chromium:1359773
Change-Id: I2a3a720021c797c62a87d10e999603ff5e29a027
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3965723
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#83825}
Use jcc where possible if using TailCallBuiltin with a condition (e.g.
in the BailoutIfDeoptimized call).
Change-Id: I160096919082b6535550c0e2053522a703c0c264
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3963994
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83823}
It makes it more difficult to navigate code.
Bug: v8:7700
Change-Id: I18175dfa9b05261e1646410b041c2efaa009d191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3967899
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83821}
Removing the nowadays unused field `allocated_code_space_` from
`WasmCodeAllocator`. Formerly, it was used when setting the code space
of a `NativeModule` to writable, but nowadays we do that per-function.
Thus, `allocated_code_space_` is only written to, but never actually
used.
Change-Id: Ia57c377518ff177e72ec5e2945db34816bd02885
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3963993
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83820}
