This prepares using ochang_js_fuzzer with foozzie. The fuzzer uses
tests from CrashTests in the corpus. This leads to a loop when
used with differential fuzzing, as foozzie dedupes failures based
on the original file path. Foozzie finds a new failure for the
existing failure in CrashTests, for which clusterfuzz creates a new
crash test and so on.
This subsumes all failures from CrashTests under the same key.
Once such a failure is reported, a developer can add it to a
mapping in foozzie.py, after which the global key can be used
again by clusterfuzz to report another failure.
No-Try: true
Bug: chromium:1044942
Change-Id: I801a23faeb0c672d6ad64b4100c463f53e36cbc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214837
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68053}
Allocating a new feedback vector happens in two steps: We create an
empty structure and then initialize the array based on the
FeedbackMetadata.When allocating a new feedback array we could trigger
a GC which might flush the bytecode and associated feedback metadata.
This shouldn't happen in normal cases, because we either allocate
feedback vector after compilation or when we reach the expected budget.
In both cases, the age of the feedback vector should be 0 and hence
bytecode shouldn't be flushed. However, with debugger enabled we may
allocate feedback vectors even when the bytecode array is old
for example: when we enable precise invocation counters. This also
causes issues in tests with --stress-flush-bytecode. In the stress mode
we flush bytecode without considering the age. Holding on to the
feedback metadata prevents crashes in such cases.
Bug: v8:10560
Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68052}
This reverts commit e270b6d615.
Reason for revert: V8 DEPS roll stuck https://crbug.com/v8/10567#c1
Original change's description:
> Roll ICU from 65.1 to 67.1 (f2223961) & correct tests
>
> Rolling to chrome/src is in
> https://chromium-review.googlesource.com/c/chromium/src/+/2155530
>
> Since auto rolling stop after 3/24/2020 and the rolling will cause
> change of test status, I get this cl ready (but not running trybot due
> to 1074260) and plan to hand roll after the submission of 2155530.
>
> Bug: chromium:1064326, v8:9515, v8:10379, v8:10380, v8:10437
> Change-Id: I19554f68cfdc5b717dfc7fc4b1222e9dc25b8d69
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158486
> Auto-Submit: Frank Tang <ftang@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67493}
TBR=jkummerow@chromium.org,machenbach@chromium.org,jshin@chromium.org,ftang@chromium.org,syg@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1064326, v8:9515, v8:10379, v8:10380, v8:10437
Change-Id: I3f4233815ed7414f2cde3d4d996696575b5f6e3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219334
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68051}
Making them private was a way to hide the constructor, we can
explicitly delete them, which give a better compilation error message as
well.
Also see: https://stackoverflow.com/q/55205874
Bug: v8:10488
Change-Id: I1c037a501c1da39f027c071e5e64d36fd1c95c6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219419
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68049}
The previous attempt failed because it uncovered an unrelated bug
(v8:10560). There are no known problems.
Bug: v8:9808
Change-Id: I360917c45d95ba39c8bea80114ea02bc5e1f83ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219936
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68048}
Temporarily disable stress-bytecode-flush on
mjsunit/regress/regress-786784 while we investigate failures related
to bytecode flushing.
Bug: v8:10560
Change-Id: Ieb5cc7ba87da04133e98c6be25c9a499d79543e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218038
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68046}
Instead of keeping a single {stepping_frame_} per native module, we now
keep one frame id per isolate. Hence, each isolate can step through a
different frame, independent of other isolates.
The on-stack-replacement of the stepping frame already works on a
per-isolate basis, since we only replace the return address of a single
frame, part of the isolate that requested stepping.
The new test (which also executes in a variant with two concurrent
isolates) revealed some more data races to fix.
R=thibaudm@chromium.org
Bug: v8:10359
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I0bb013737162bd09b9f4be9c08990bca7bf736ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214838
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68045}
Make sure that any GCs required for off-thread heap merging happen
before any off-thread handle transferring (both transferring using
OffThreadTransferHandle, and the handles created for the string slot
fixups). This is to avoid the marker from walking Handle roots that
point into off-thread pages which the sweeper doesn't see (and can't
clear mark bits on)
Now, the merging and handle creation is atomic as far as the GC is
concerned. The merging is done before handle creation to avoid the
incremental marker from entering off-thread pages, but we ensure that
the raw objects pointers that point into the off-thread pages (which
are used for creating the main-thread handles) stay valid until the
handle creation completes.
Since handle transfer now happens in the middle of publishing, this
patch also moves the OffThreadTransferHandleStorage ownership over to
OffThreadHeap. This requires some header juggling to avoid leaking
OffThreadTransferHandleStorage into the off-thread-isolate header.
Bug: chromium:1086478, chromium:1011762
Change-Id: Id5e7622d6b5520400a4872c5f6ad396c74b30ca6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218058
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-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/master@{#68043}
Since the interpreter is only used for internal testing now, it does not
have an associated frame type any more. We thus cannot call external
functions any more, since a stack walk would not know how to handle
interpreter frames.
All code for calling external (imported) functions is dead by now, so
this CL removes it.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: If4b56b93e63002a1e5463f278f0271eb413762eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218287
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68039}
In BinaryOpAssembler::Generate_BinaryOperationWithFeedback, the
feedback is stored only after the respective builtin/runtime call.
If this call throws an exception, the feedback is lost, leading
to a deopt loop in some cases. This CL fixes that issue by writing
the gathered feedback before passing control to the builtin.
Bug: chromium:1077197, v8:9441
Change-Id: I20e4b14815520224e2c6f8af1af6a89f754ccddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202904
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68038}
This is a reland of 6204768bab
The original issue exposed the problem that NumberEqual performs
implicit conversion of oddballs to numbers, which is incorrect for
abstract equality comparison (i.e. 0 == null must not be true).
This reland fixes this by applying the following steps:
* Introduced a new kNumberOrBoolean value for CompareOperationFeedback,
CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode.
* In CodeStubAssembler::Equal: Further distinguish between boolean and
non-boolean oddballs and set feedback accoringly.
* In JSTypedLowering: Construct [Speculative]NumberEqual operator with
CompareOperationHint::kNumberOrBoolean, when this feedback is present.
JSOperatorBuilder and operator cache are extended accordingly.
* In SimplifiedLowering: Propagate a UseInfo with new
TypeCheckKind::kNumberOrBoolean.
* This leads to the generation of CheckedTaggedToFloat64 in
RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean.
* In EffectControlLinearizer: Handle this new mode. Accept and convert
number and boolean and deopt for rest.
Original change's description:
> [turbofan] Improve equality on NumberOrOddball
>
> This CL cleans up CompareOperationFeedback by replacing it with a
> composable set of flags. The interpreter is changed to collect
> more specific feedback for abstract equality, especially if oddballs
> are involved.
>
> TurboFan is changed to construct SpeculativeNumberEqual operator
> instead of the generic JSEqual in many more cases. This change has
> shown a local speedup of a factor of 3-10, because the specific
> operator is way faster than calling into the generic builtin, but
> it also enables additional optimizations, further improving
> runtime performance.
>
> Bug: v8:5660
> Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67645}
TBR: tebbi@chromium.org
Bug: v8:5660
Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68037}
Embarrassingly, while integrating VerifyRegExpSyntax into SpiderMonkey,
I realized that I had refactored away the RegExpCompileData* argument,
which is necessary for emitting error messages when parsing fails.
Bug: v8:10406
Change-Id: Iaa8cd1f944bbf058ccc03c052b5ec0563b7c2e99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219415
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68033}
This reverts commit dfdef88547.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Mac/2718?
Original change's description:
> [wasm-simd] Fix extract lane unsigned extend
>
> The interpreter is missing a static cast when extracting lanes smaller
> than int32_t and doing an unsigned extend. The array in Simd128 is
> signed, so a direct cast to uint32_t will be a signed extension. The fix
> is to, in the unsigned case, cast to unsigned (of the appropriate size)
> first, then cast to uint32_t.
>
> Change-Id: Ifabb5b9690f08ad505ac94b84908db0970581818
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216721
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68029}
TBR=gdeepti@chromium.org,zhin@chromium.org
Change-Id: Icdd0e705f4c7252aef2cadaa39ec52204b5c6093
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219412
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68030}
The interpreter is missing a static cast when extracting lanes smaller
than int32_t and doing an unsigned extend. The array in Simd128 is
signed, so a direct cast to uint32_t will be a signed extension. The fix
is to, in the unsigned case, cast to unsigned (of the appropriate size)
first, then cast to uint32_t.
Change-Id: Ifabb5b9690f08ad505ac94b84908db0970581818
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216721
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68029}
all_true uses pcmpeqd which takes a memory operand, but needs to be
128-bit aligned, which we don't support yet.
Bug: v8:9198
Change-Id: Ia0caaaa76b1103ba538252181ef93e8557fb4739
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218887
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68027}
Implementation for ia32 and x64, arm and arm64 simply bailout now, will
be implemented later.
Bug: v8:9909
Change-Id: Ieea02baeb68f5c947d1182450f9f80c3e19e07ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216930
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68025}
Port 839e9695ca
Original Commit Message:
Implemented for ia32, x64, arm, arm64, all in one patch (phew). The
code is simple enough (short paragraph) that are the same as TurboFan
codegen.
R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I7731e12622bbc04a5fe043217597e4dd749df030
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218640
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#68024}
Implemented for ia32, x64, arm, arm64, all in one patch (phew). The
code is simple enough (short paragraph) that are the same as TurboFan
codegen.
Bug: v8:9909
Change-Id: Idbc1cbd58c16e455b1656c2367c8d9db10308e35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208610
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68022}
This is a partial reland of https://crrev.com/c/v8/v8/+/2199640 . It
includes removing an unused field.
Change-Id: Iffc56a2bee751758dcba5c1ec162dcf9258db62d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216303
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68021}
Display register allocation live ranges alongside sequences in
turbolizer.
The existing --trace-turbo flag now also outputs the register
allocation data as part of the json file alongside the
instruction sequence data that is already produced before and
after register allocation is performed. This data includes live
range intervals for each virtual and fixed register and the state
of their assignments.
This json data can now be displayed in turbolizer alongside the
instruction sequences. The information is presented as a grid,
with each grid cell representing a LifeTimePosition of a certain
virtual register, determined by the column and row indices
respectively. Each LifeTimePosition is shown to be part of an
instruction id which itself is shown to be part of a block id.
Each interval is shown as a coloured rectangle positioned over
the relevant cells, and displaying text to indicate the state of
their assignment.
The Resizer object has been extended to allow the grid's html
panel to be varied in size in the same manner that the left and
right panels can be. The size of the grid itself must also be
adjusted whenever the div container changes size.
The RangeView class is introduced and is created and held by the
single SequenceView object used to display the
InstructionSequence data before and after register allocation.
A checkbox allows the user to show/hide the range view, this is
disabled when register allocation data is not provided or more
than 249 instructions are in the sequence. The latter being
required due to the css grid-row-col limit of 1000 alond with
helping alleviate performance issues. The SequenceView object
tracks the phase index currently selected as well as whether or
not it is currently being shown. This ensures that the RangeView
is not hidden and shown when switching between before and after
register allocation, allowing for a smoother transition between
the two. The scroll position is also saved and restored for
convenience.
The data about the instruction sequence required for the display
is held by the RangeView object and reset whenever a new
instruction sequence is shown. The grid div must sync its scroll
with the headers and row labels so as to ensure a consistent
view. The register allocation data is extracted from the json,
with each register row showing all intervals within the relevant
ranges. When the view is switched between before and after
register allocation, the relevant intervals are swapped in.
Bug: v8:7327
Notry: true
Change-Id: I183535a2410a7d663382f387199885250fb98691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184232
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68019}
This is a partial reland of https://crrev.com/c/v8/v8/+/2199640 . It
allows scoped lookups to not crash during CompileCurrentAst, fixes the
formatting in an error message, and includes an extra line for
convenience when generating macros for bitfields.
Change-Id: I7ed9f7d76b3ce5e2cc0f2580d7ba1953da340ae8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216301
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68018}
- Moves some CSA macros back into the global namespace, and uses
Torque's new global namespace feature to disambiguate the calls.
Bug: v8:9891
Change-Id: I6a94ee04daed1e6a8f672b2eaa12161ab998f14c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216932
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68017}
All strings in the internalized string list now have them.
Bug: v8:10506
Change-Id: I68feb34d0dc424465a53ac73a5d6b5297e29dd00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218032
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68014}
INTPTR_PARAMETERS is deduced from reg, which is an TNode<IntPtrT>.
Bug: v8:9708, v8:6949
Change-Id: I84c4e5803602ecc2d9284bce46409a384e93a035
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212265
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68009}
Since now all phases have the same order (or the reverse) we can share
only one container that would specify the traversal order.
We still need a queue that will be used for revisiting purposes in
PROPAGATE and RETYPE.
Bug: v8:10424
Change-Id: Iab1e3c3cf6ffd342240d43be3b8ac77812aff211
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154201
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68008}
We now have one initial phase (before PROPAGATE) that generates the
traversal that the subphases are going to take. Generates post-order
starting from End for RETYPE and LOWER, and the reverse for PROPAGATE.
As a note, LOWER could use either PO or RPO.
Bug: v8:10424
Change-Id: I7435d681aba012b4f5e5ecd971bfa1d88bfb8b3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154785
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68007}
Also remove a version that was only used once.
Bug: v8:9708, v8:6949
Change-Id: Ifd65af3866a3740d8da6d4501445b25a48d7219a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212264
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68006}
The `slot` parameter is expected to be a UintPtr.
Bug: v8:8888
Change-Id: Ia1137cd5af3d3aa0b00e9bf194661067c37332b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215047
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68005}
This CL brings unary op assembler structure closer to that of binary
ops assemblers:
- Decrement, Increment, Negate call into UnaryOpWithFeedback,
- which takes lambdas specifying smi, float, and bigint logic.
- BitwiseNot is different in that it still dispatches using
TaggedToWOrd32OrBigIntWithFeedback.
- These methods are all implemented in the (hidden)
UnaryOpAssemblerImpl class.
- The header only exposes UnaryOpAssembler with the bare minimum of
API.
The last point is the remaining major divergence from binary op
assemblers. I just like how this avoids useless implementation details
in the header.
Bug: v8:8888
Change-Id: I0ac4695483950356885301234d58c1900904aa92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214830
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68004}
