This reverts commit 05a80427dc.
Reason for revert: Getting timeouts on some slow bots.
Original change's description:
> [wasm] Do not add too much code at once
>
> Especially on arm64 we have a rather low code space limit (128MB), so it
> can happen that a background thread generates more code in one batch
> than can be held in a single code space. This case is not implemented
> yet.
>
> This CL implements this by never batch-adding more than half of a code
> space.
>
> In order to test the implementation, we add a new flag called
> --wasm-max-code-space-size-mb which can be used to artificially lower
> the code space size limits in tests.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13436
> Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84245}
Bug: v8:13436
Change-Id: I0b2492eb7fee40b7d62b3b3a8fb19a4bc7fda26b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4025546
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84248}
The test was introduced in https://crrev.com/c/4023072, but times out in
gc-stress.
R=leszeks@chromium.org
Bug: v8:13436
Change-Id: I2991083a2a229cbc5e307aebf1a44acf169ac4fb
No-Try: true
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023860
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84247}
When runnig cppgc_unittests in a cppgc standalone build, the test
ConcurrentSweeperTest.IncrementalSweeping fails. This is becuase
TestPlatform::RunAllForegroundTasks was actually not running all
tasks becasue v8::platform::PumpMessageLoop only runs a single task.
Change-Id: Ie68eee369abd12edcf04e697a1d8ca574059d160
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026163
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84246}
Especially on arm64 we have a rather low code space limit (128MB), so it
can happen that a background thread generates more code in one batch
than can be held in a single code space. This case is not implemented
yet.
This CL implements this by never batch-adding more than half of a code
space.
In order to test the implementation, we add a new flag called
--wasm-max-code-space-size-mb which can be used to artificially lower
the code space size limits in tests.
R=jkummerow@chromium.org
Bug: v8:13436
Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84245}
This is a reland of commit 5223f19753
Add new nodes to EnsureTagged DCHECK and drive-by fix missing safepoint
in StringCharCodeAt which was the root cause of JetStream failures.
Original change's description:
> Reland "[maglev] Float64 bitwise ops as truncation + Int32"
>
> This is a reland of commit 2adc620152
>
> Rebased on fix which changes Int32 from always being checked as Smi,
> to being explicitly checked as Smi when used by SignedSmall (and not
> checked to be Smi in the new truncating code, but instead allowing
> overflow into a HeapNumber).
>
> Original change's description:
> > [maglev] Float64 bitwise ops as truncation + Int32
> >
> > Implement truncating bitwise ops (ops that treat their input as a number
> > truncated to int32) for Float64 representation, by adding truncation
> > operations for Float64 and tagged Number.
> >
> > Bug: v8:7700
> > Change-Id: I36f423ba8d5332e8eb8c3d6357bbaed7ea4bbb37
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013685
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#84182}
>
> Bug: v8:7700
> Change-Id: I518f3414aa98eb1d2edf61980554e4682bd83c8a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022710
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84234}
Bug: v8:7700
Change-Id: I47af624c11e586af2914d51b13d22f6a863ef13f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020304
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84244}
The condition clearing the "known HeapObject" bit was wrong -- it was
checking whether the _map_ was a HeapObject (spoiler alert, it is), not
whether it was the map _of_ a HeapObject, i.e. not a HeapNumberMap which
returns true for Smis.
Bug: v8:7700
Change-Id: I5af4c1a662bb16bacdfcf178819d912332ecefd6
Fixed: chromium:1383712
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023077
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84243}
Rename the '--wasm-max-code-space' flag to
'--wasm-max-committed-code-mb'. We will introduce a new flag to set the
maximum size of a wasm code space, so the old name would be misleadingly
close to the new flag.
R=jkummerow@chromium.org
Bug: v8:13436
Change-Id: I7a86300e4f25858add1a62f9989189035ea855ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022709
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84242}
Modify the existing x64 trap handler test to support arm64 too.
Bug: v8:13383
Change-Id: I23eb8276ad94289e9a27b756d51040321778d912
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990564
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84241}
This is a reland of commit 936b61a209
Change compared to original: Fix parameter types for CallRuntimeStub
in Liftoff.
Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}
Bug: v8:7748
Change-Id: I67737150252b844a296338db0c60f76b470aa43b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022711
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84240}
This prepares work for speeding up gcmole infrastructure by adding
more checks and testing.
- Add a presubmit check that verifies gcmole directives in gn files.
- Simplify gcmole directives in gn files. Drop all but the
architecture property as the others were unused. Simplify regular
expressions.
- Fix some gcmole directives (fly by - only on untested
architectures).
- Add a python test for the changed function in gcmole.py. There's
no other testing yet and this starts somewhere. The test simulates
real BUILD.gn files via checked-in test data.
Bug: v8:12660
Change-Id: I9ca3152b2c3b806de5d4509c152283b36294950d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020268
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84239}
Reland of https://crrev.com/c/3998633.
Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.
However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.
However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.
Bug: v8:13267
Change-Id: Idc257ecf6b6af09a379bdd7cd7c1d4a5e46689c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4016715
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84237}
This is a reland of commit 2adc620152
Rebased on fix which changes Int32 from always being checked as Smi,
to being explicitly checked as Smi when used by SignedSmall (and not
checked to be Smi in the new truncating code, but instead allowing
overflow into a HeapNumber).
Original change's description:
> [maglev] Float64 bitwise ops as truncation + Int32
>
> Implement truncating bitwise ops (ops that treat their input as a number
> truncated to int32) for Float64 representation, by adding truncation
> operations for Float64 and tagged Number.
>
> Bug: v8:7700
> Change-Id: I36f423ba8d5332e8eb8c3d6357bbaed7ea4bbb37
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013685
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84182}
Bug: v8:7700
Change-Id: I518f3414aa98eb1d2edf61980554e4682bd83c8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022710
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84234}
... which checks if we need to add deoptinfo at runtime.
This allows us to delay SetAccumulator and remove the boolean
argument in the ReduceCall functions.
Bug: v8:7700
Change-Id: I87cc8937ae05dce13c80b3e2fe00d031a483ef19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023066
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84233}
This constant wasn't really used anymore anymore, so we can drop
this constant and initialize the --concurrent-marking flag from
V8_ATOMIC_OBJECT_FIELD_WRITES instead.
Bug: v8:13267
Change-Id: I2533d80cd08fd799441a7dba764fd392bb9151d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020428
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84232}
For SignedSmall binary ops, we know that the output has to fit in a Smi.
So, emit a Smi check eagerly after these operations, so that future Smi
untagging knows that it doesn't need to do a check.
Bug: v8:7700
Change-Id: I117c55caa5e2ebe870fd964908564d74df726546
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020434
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84223}
After a cache hit we need to get a fresh pointer to the {WasmModule}
from the {NativeModule}. The old {NativeModule} might have died at that
point, including the old {WasmModule}.
R=ahaas@chromium.org
Bug: v8:13472
Change-Id: I101a2bb6e381d09a87d8de352030c5533541270e
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020244
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84222}
This reverts commit 936b61a209.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20no%20pointer%20compression/2000/overview
Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}
Bug: v8:7748
Change-Id: Ia74e49147d230f9217ebeb2bf435d10d8f93126e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020457
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84221}
This is a reland of commit 109e19554b
Original change's description:
> [maglev] Unify call building functions
>
> ... so that we have more reduce/inline opportunities.
> It changes CallArguments to hold a vector of ValueNodes.
>
> Change-Id: I9c282631c0dcc2756edc2e2c1f892c3855e1286d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020381
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84205}
Change-Id: Ib27cdcc05b45ea5366c7790f849dcfed4300bbb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023067
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84220}
JS numbers flowing into Wasm as i31ref should be canonicalized at the
boundary. In-range numbers get canonicalized to Smis, and out-of-range
numbers to HeapNumbers. This way, casting to i31ref, or checking for
i31ref when casting to other types, is reduced to a Smi check.
Bug: v8:7748
Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84219}
This CL fixes the bug where x ^ x is reduced to Int32Constant(0) for
both word32 and word64.
Bug: chromium:1383362, v8:9407
Change-Id: I8a2ed879f0626071f560cc5ba8c21ef2d4107e62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020424
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84218}
This CL adds a check that the actual arguments passed to runtime
functions (via `VarState`s) match the declared parameters in the
signature.
We have many mismatches, which are probably harmless now but can easily
lead to bugs in the future.
In turn, we remove a few DCHECKs that are redundant now.
R=ahaas@chromium.org
Change-Id: I4038cc24e3a9b44ae9fdfc5a204be351784ae5e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020294
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84216}
{kPointerKind} is misleading, and can be confused with {kRef}. Rename to
{kIntPtrKind} to make it clear that this is a pointer-sized integer
type.
Also rename {kTaggedKind} to {kIntTaggedPtrKind}, which is a bit bulky
but again prevents against confusion with {kRef}.
This is a pure rename, without auditing if all uses are correct.
R=ahaas@chromium.org
Change-Id: I2c512be1510f102422bb78e5bc8a46523c4fa0ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020412
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84213}
Previously, once after an error was reported, following errors were ignored
even if they had occured in prior lines. Strict octal error and conflicting
variable declarations error could be missed under this implementation.
This patch solves this problem by making an error replaceable.
Bug: v8:13187
Change-Id: I8295baf0db757a5c1b504920cb274cdee78f5055
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4019398
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84212}
Since the introduction of actual references, we should either use {kRef}
for tagged values or {kSmiKind} for tagged values that are known to be
Smis. {kTaggedKind} is misleading as it looks like it would be treated
as a tagged references, but it is actually not.
R=ahaas@chromium.org
Change-Id: Ib74d8365497eeaa9ff9e9bbcbd204233451b498f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84210}
The bug was introduced in https://crrev.com/c/4014299; we should only
validate lazily compiled functions here, as the comment above explains.
R=ahaas@chromium.org
Bug: v8:13447, chromium:1383190
Change-Id: Icfdaf052bee49544c8e204a55bc83bd9e9ca068a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020295
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84209}
When the c-api gets called back from WebAssembly, the context set in the
isolate may not be valid. It is therefore necessary to set the context
when the c-api gets entered from WebAssembly.
R=jkummerow@chromium.org
Bug: v8:12852
Change-Id: I279c22bbfb2468133732b611e1bdf00f04807e0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020382
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84206}
... so that we have more reduce/inline opportunities.
It changes CallArguments to hold a vector of ValueNodes.
Change-Id: I9c282631c0dcc2756edc2e2c1f892c3855e1286d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020381
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84205}
Client isolates need the incremental marking barrier for objects in
the shared heap. The marking barrier for the shared heap can be
enabled either with or without incremental marking in the client
isolate's local heap.
Client isolates get a new marking worklist in the MarkingBarrier
class for marking of shared objects. Shared objects will always be
pushed into that worklist for tracing. MarkingBarrier can be enabled
for shared marking and/or marking of local isolates.
Bug: v8:13267
Change-Id: I0b60134432de9af3c76e24620816555ee49da1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4001768
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84202}
The wrapper obects for the debugger displayed e.g. in dev tools
contain a proper `null` value already.
Note: This only affects the printing of wasm tables in the test.
Change-Id: I3c2e9580b0a3983b66b9c3e2e16e5a2b322a9ff7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020261
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84201}
