When calling the {Isolate::StackOverflow} method, we should not have
overflown the stack limit by too much. Otherwise there might not be
enough space on the stack for handling the stack overflow exception.
This DCHECK would have failed before landing https://crrev.com/c/3059074
and https://crrev.com/c/3059075. If it fails, we might need to add more
special stack checks also in other places. Such failures should not be
considered security issues per se, but we should try to fix them to
avoid potential issues.
R=jkummerow@chromium.orgCC=ahaas@chromium.org
Bug: v8:12017
Change-Id: I25e42a20d3fcc981c266ae998f52b3f090237297
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059076
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75998}
This reverts commit bce81d6be0.
Reason for revert: Newly introduced test is flaking, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20ASAN/41030/overview or https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/43171/overview
Original change's description:
> [wasm] Support partial serialization of modules
>
> At the moment a WebAssembly module can be serialized successfully when
> all functions were compiled with TurboFan. However, for some functions
> it may not be necessary to be compiled with TurboFan, e.g. for functions
> where Liftoff code is as good as TurboFan code.
>
> With this CL we allow WebAssembly modules to get serialized even when
> not all functions are compiled with TurboFan. Missing functions are
> marked as missing in the serlialization. Upon deserialization, missing
> functions either get compiled by Liftoff, or initialized with a
> lazy-compilation stub, depending on the V8 configuration.
>
> Bug: v8:11862
> Change-Id: Ic833a17639bf841c5def6fe3c35173fe0376c246
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960209
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75987}
Bug: v8:11862
Change-Id: I5445c097ec47f407e5f951d4cf6d2168113f80e8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060484
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75997}
If a GC happens between Code object allocation and Code finalization,
we might have invalid embedded object references. We fallback and patch
the refernces back to handles, then unbox the handles and relocate.
Bug: v8:11872
Change-Id: I3a7b050c20179c1708eef343ec8266441ab5dca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059689
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75996}
This adds a code comment before the OOL code for the special stack check
for a large frame. Otherwise it is hard to see where it begins in the
code, and it might be unexpected to see that block of code at the end of
a Liftoff function.
Drive-by: Replace another "out of line: " comment by "OOL: ", which is
typically understood equally well.
R=ahaas@chromium.org
Bug: v8:12017
Change-Id: Ie8b243cedebe979ca46e0515a9fdd0695ab58304
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059081
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75995}
The JS API constructor was renamed to "WebAssembly.Tag" to match the
spec:
https://github.com/WebAssembly/exception-handling/issues/159
Rename "exception" to "tag" throughout the codebase for consistency with
the JS API, and to match the spec terminology (e.g. "tag section").
R=clemensb@chromium.org,nicohartmann@chromium.org
Bug: v8:11992
Change-Id: I63f9f3101abfeefd49117461bd59c594ca5dab70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053583
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75994}
Clearing cached PropertyAccessInfos is used for stress-testing. Note
all this will soon be removed.
Bug: v8:7790,chromium:1234288
Change-Id: I4576563375b65830296cad295342823700d13b3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059696
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75992}
Add an explicit check for the available stack space before allocating a
large frame. Even though this typically does not cause problems on ia32,
we should do it to be consistent with other platforms and with TurboFan
code.
This follows the same structure as on x64: https://crrev.com/c/3059074
A follow-up CL will add a DCHECK to verify that we never overflow the
stack space by more than 4KB (https://crrev.com/c/3059076).
R=ahaas@chromium.org
Bug: v8:12017
Change-Id: Ifffe56f29feae14545e6f70e30a1c94c5eabad6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059075
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75991}
Add an explicit check for the available stack space before allocating a
large frame. Even though this typically does not cause problems on x64,
we should do it to be consistent with other platforms and with TurboFan
code.
After also fixing ia32 (https://crrev.com/c/3059075), we can add a
DCHECK to verify that we never overflow the stack space by more than
4KB (https://crrev.com/c/3059076).
R=ahaas@chromium.org
Bug: v8:12017
Change-Id: I4f407dc6a83d4a71636066777706f23d05002111
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059074
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75990}
The comment is a left-over of the state before
https://crrev.com/c/3055302. It should have been removed as part of that
CL.
R=ahaas@chromium.org
Bug: v8:12017
Change-Id: Ic5234b230b3eda30e9a4a346e8c3b83c813a5dbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059078
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75989}
This will change the behavior of %TypedArray%.prototype.fill.
Bug: v8:11111
Change-Id: I66e7d3decf07663a6497c3c86374b3c77ab6a682
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056977
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75988}
At the moment a WebAssembly module can be serialized successfully when
all functions were compiled with TurboFan. However, for some functions
it may not be necessary to be compiled with TurboFan, e.g. for functions
where Liftoff code is as good as TurboFan code.
With this CL we allow WebAssembly modules to get serialized even when
not all functions are compiled with TurboFan. Missing functions are
marked as missing in the serlialization. Upon deserialization, missing
functions either get compiled by Liftoff, or initialized with a
lazy-compilation stub, depending on the V8 configuration.
Bug: v8:11862
Change-Id: Ic833a17639bf841c5def6fe3c35173fe0376c246
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960209
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75987}
Cppgc reports used bytes statistics to CppHeap. CppHeap should forward
the stats to v8. However, if we are not allowed to trigger a GC, CppHeap
will cache the stats until the reporting.
On GC finalization, CppHeap resets v8's counters to the current marked
bytes counter.
If the last reported stats before GC finalization are cached, CppHeap
doesn't clear the cache on GC finalization. On the next stats reporting,
CppHeap will report the cached values. If the cache is a decrease that
is larger than the current marked bytes, a DCHECK in
LocalEmbedderHeapTracer::DecreaseAllocatedSize will fail.
Bug: chromium:1056170
Change-Id: I47933abc3e5f5c4a91454e0ec03adde5cf61d8fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056970
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75986}
- Make sure we use fast prechecks in the header files
- MicrotaskQueue::CallEnqueueMicrotask returns a Smi instead of a
more costly undefined value (the return value is enforced by the
calling convention, but unused)
- Merge FireMicrotasksCompletedCallback into OnComplete
Change-Id: I3797b946bcffb6349e5693c41478bd2bad1f93fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024154
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75985}
This fixes the youcompleteme config script to look for ninja_output.py
in tools/vim instead of tools/ninja (it was moved there in
https://crrev.com/c/2797536), and makes a minor adjustment for python3
compatibility.
R=machenbach@chromium.org
Bug: v8:11879
Change-Id: Ia825903fb6019865244c5529bf2d23935a10ad5e
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059077
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75984}
If v8_enable_runtime_call_stats == false, we don't need
TracingFlags::is_runtime_stats_enabled and can save a bit of code and
needless overhead.
Bug: v8:11299
Change-Id: Ia5ec51c29b2408b77b65984c5bba0ae16e0de243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024155
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75983}
Due to missing locks, there is a race between AllocatePagesAt (or
ReserveForSharedMemoryMapping) and other functions that modify
std::sets in RegionAllocator (e.g. AllocatePages or ReleasePages).
The CL adds locks to AllocatePagesAt and ReserveForSharedMemoryMapping.
Bug: chromium:1232067
Change-Id: I0ec503ab1ab432952ea067eb916299ea88566879
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056985
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75981}
If context filtration fails, ensure that we still include an empty
sample. This ensures that we can properly terminate stacks.
Bug: chromium:956688
Change-Id: I3edeb3434960c420e24827c209055f7c378361bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3058053
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#75980}
- goma cache silo is a builder to build the same target with cache silo.
This is needed for fair build performance comparison between reclient
and Goma.
- reclient compare is a builder to verify artifacts generated in remote
and that generated locally matches.
Bug: chromium:1233780
Change-Id: I5854d20880e972a07fa09cfc5d4a6f9385844fbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3058059
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75979}
InterpreterOnStackReplacement_ToBaseline spills the accumulator register
without a frame, but can then call kInstallBaselineCode. If that
function then allocates, then the GC will see an invalid stack.
Fix this by making sure that the accumulator register is spilled inside
the internal frame of the kInstallBaselineCode, and either don't spill
it at all outside that frame, or at least make sure that we pop/re-push
the spilled value so that it moves inside the frame.
Bug: v8:11420
Change-Id: Iad2aa718b0477ff960544d881fecae9efcbeef54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059072
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75978}
The test makes sure that JSON parsing doesn't stack overflow if given a
deeply nested JSON object. This deep nesting makes the test slow, so we
can test ~the same thing by lowering both the nesting and the stack
size.
Bug: v8:12029
Change-Id: I689ffc1b9db167a1cf1de93beeb09c89e03264a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059685
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75976}
Use the result of scripts.find() instead of using operator[] when
looking up scripts. This avoids an ugly const_cast, and avoids doing the
lookup twice.
Change-Id: I7c1a6be28928e2e3d928c389328be8785be3cff7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056989
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75974}
is_deprecated and is_stable are mutable and can be changed
concurrently. We protect against changes through dependencies. CHECKs
on such fields are invalid.
Bug: v8:7790,chromium:1234206
Change-Id: I9bb7fab0342e0e2c33377c162b1912a8f93e760b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059682
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75973}
The test currently fails on machines with sparkplug enabled:
```
Flag --sparkplug: value implied by --jitless conflicts
with explicit specification
```
And passes on platform without sparkplug.
Bug: chromium:1233401
Change-Id: Ia0277f8d356e34efb611ca9960c11ec78b9b94ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3058300
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75970}
R=leszeks@chromium.org
Bug: chromium:1233401
Change-Id: Ieaf7513d2dbd9bc84a996defbf0a929d35befa36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059082
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75967}
We add new alternative "new_object" in order to
emit new struct and array types. We check whether
heaptype is struct or array type so we could emit
"NewDefault" or "NewWithRtt". The additional methods
(IsArray/StructType, GetArray/StructType) was added to WasmModuleBuilder.
Bug: v8:11954
Change-Id: I7a0e73edfbaa49beb1efd60b0f1b9916dc50df22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056459
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Rakhim Khismet <khismet@google.com>
Cr-Commit-Position: refs/heads/master@{#75966}
FP Div, Min and Max are added in this CL.
Opcodes are also reordered in macros to match the
instruction selector.
Change-Id: Idd6909721b0d06d523c93873e5faff39449d937c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3058294
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75965}
Previously we do not tier down from baseline to interpreter, which
breaks per-bytecode side effect checks (to check whether e.g. we are
mutating a temporary object, which is not considered a side effect).
R=leszeks@chromium.org
Bug: chromium:1233401
Change-Id: Ie08b5352aa4c124421b4c9abce18326938bbc822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056981
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75963}
Previously we'd report all property edges with symbol names as <symbol>,
which was not very useful, especially with private class fields now
seeing more adoption.
Fixed: chromium:1232467
Change-Id: I53cf0811c4b83d016b988b687c6decbddd3c2fdd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055309
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75962}
Found these when compiling the arm64 simulator for MSan (Release) and
ASan (Debug and Release). Depending on the exact configuration (and
compiler), different functions will get inlined and different symbols
need to be available at link time.
1) Since GetRecoveredTrapCount is used in a unittest, it needs to be
exported.
2) The thread-local g_thread_in_wasm_code cannot be exported on
Windows, hence it cannot (safely) be used in unit tests. Use the
{GetThreadInWasmThreadLocalAddress} function instead, which will
return the address of that thread-local variable.
R=ahaas@chromium.org, mseaborn@chromium.org
Bug: v8:11955
Change-Id: I118f60c1580a8362f8232541576a1c41da7042bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049077
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75960}
Use write barrier when storing code into JSFunction::Code field.
Earlier, code from SharedFunctionInfo was always a builtin and hence
it was safe to skip write barrier there. With Sparkplug we could
also store baseline code and hence it isn't safe to skip write barrier.
Change-Id: I6a68ac759d619cdbeec8d4a37e9493d46f7aa790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056982
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75959}
The OSR entry stack check is needed as a function entry stack check to
make sure the call isn't overflowing, but emitting it as part of the
loop peeling meant that it would be within any exception handler ranges
that the loop is in.
In particular, this meant that code like this:
try {
loop {
OSR();
}
} catch {}
would logically insert the entry stack check inside the try, and thus
stack overflows of the function call would be caught within the
function, and the function could continue runnning in an overflown
state.
Bug: chromium:1232875, chromium:1034322
Change-Id: I846c6f520fd3a897da016132419ad48043859c33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056980
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75958}
Drive-by: Remove invalid DCHECK(!is_deprecated) since we cannot
guarantee this in a concurrent setting.
Drive-by: Instead, check for deprecation during dependency validation.
Drive-by: Remove addtl. invalid or outdated DCHECKs.
Bug: v8:7790
Change-Id: Ia77a82976b987fe1eaca6178dac6c7b75fbf98fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041666
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75957}
Fix ia32 for v8_enable_webassembly=false.
This is not a configuration that we test on CQ or the waterfall, but
it was working at some point so this CL makes it compile again.
R=zhin@chromium.org
Change-Id: I78dafe08199c89ec24613a62a3085e923a51b43e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056450
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75953}
This means that we are now background serializing
RefSerializationKind::kBackgroundSerialized classes on all configs.
Bug: v8:7790
Change-Id: Iaa54718303e07e37a95d3f54d0c4c173d4174967
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056453
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75952}
.. instead of recalculating them at the risk of getting different
answers.
In a concurrent setting, repeated type/rep calculations are not
guaranteed to return the same answer. Instead, calculate them once and
pass them into dependency creation methods.
Note with this CL we now get the type/rep off the holder map and not
the field owner map. The results should be identical and behavior
should not change (verified by CHECKs).
Bug: v8:7790
Change-Id: I2b4c3bb8907082c69448ca743d3c8740cd8f71f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055306
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75951}
