This is a partial revert of https://crrev.com/c/2457669/.
This change is slightly longer (in code-generator-x64.cc) because we
also implement support when SSE4_2 is not supported (the reverted change
seems to assume SSE4_2, which is not always the case). This code
sequence is from https://github.com/WebAssembly/simd/pull/412.
Bug: v8:11415
Change-Id: I3eef415667b4142887cf1c449d27d19ba5bbd208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683219
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72611}
Port 68105996e0
Original Commit Message:
WasmCompileLazy needs to save the content of vector
parameter registers. If Simd is not enabled or the hardware
does not support Simd operations then we need to saves the value of
Double registers instead, therefore we need a way to retrieve the
value of "CpuFeatures::SupportsWasmSimd128()" in builtins
during runtime.
R=mfarazma@redhat.com, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I523f1353c61942acaa97c11637342b5be3d39b9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684980
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72610}
Implements https://github.com/tc39/ecma262/issues/2034
Currently the token sequence `for (async of` is ambiguous. It can be the
prefix for either `(async of => {};;);` or `for (async of foo);`. This
CL disallows the token sequence.
Note that `for await (async of` is still allowed, since there is no
C-style `for await (;;)`, and thus no ambiguity.
Bug: v8:11412
Change-Id: I3fede83a69420996baa2bc8b6c1cff000535d990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683221
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72607}
- Removes kPadArguments boolean.
- Changes ShouldPadArguments to ArgumentPaddingSlots to reflect
that on some architectures more than 1 padding slot may be needed.
- Adds AddArgumentPaddingSlots and ShouldPadArguments convenience
functions.
Bug: v8:9198
Change-Id: Iba87518e071a75fb951b490d3f75a87ca715cc23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679109
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72605}
Port 3b6eb33543
Original Commit Message:
Prototype these 6 instructions on arm:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
For all these instructions we rely on having Q registers that map to S
registers, which means we can only use q0 to q7. We fix the src/dst
to q0 arbitrarily.
R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Bug: v8:11265
Change-Id: Ibef0b05fe1066cd79ddcda12787441b09cc8ede2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684360
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72600}
This very large changeset adds support for RISC-V.
Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
v8_generate_external_defines_header has been enabled for a couple of
weeks now with no problems, so this removes the hybrid state where
V8_GN_HEADER was defined on the command line along with the other
defines.
Bug: v8:11292, v8:11341
Change-Id: Ie78f00afe5d1cbca751101a7beb61a18c7d86d04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681947
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72597}
This CL adds support for generating acquire/release accessors on class
fields. Adds first use of this new feature (@acquireRead and
@releaseWrite) on FunctionTemplateInfo::rare_data.
Bug: v8:7790, v8:11122
Change-Id: I98f533807ab784d8667fd43564fe84686d27830c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679684
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72596}
This fixes a build problem in gcc, where the constexpr function
SwissNameDictionary::SizeFor uses the non-constxpr function
SwissNameDictionary::IsValidCapacity in a DCHECK.
Bug: v8:11388
Change-Id: Iaeb2b80bb72da3a9c895aa33977c160533019c35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684514
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72595}
The is_awaiting bit on async generators distinguishes waiting on an
await. When the async generator resumes from an await, the is_awaiting
bit is cleared.
It is possible through overriding Promise#constructor that `await`
throws *after* setting is_awaiting. There is an implicit try-catch
around the body of the async generator such that, usually, caught
exceptions would clear the is_awaiting bit. However, the exception
thrown from a monkeypatched Promise#constructor can be caught by script,
and thus never clear the is_awaiting bit.
This CL sets the is_awaiting bit *after* `await` completes, with the
exception of the return resumption. It is not possible to have the
exception thrown by the await in the return resumption be caught by
script.
Bug: chromium:1171667
Change-Id: I0b615617a5c949f03350ab0f06c42920d43b5488
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659508
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72593}
In particular: remove PossiblyBackgroundSerializedHeapObject in favor of
either SerializedHeapObject or BackgroundSerializedHeapObject, depending
on the (existing) argument to the ObjectRef constructor.
Bug: v8:7790
Change-Id: I0a67872c377107799233742cc7774bea62811d0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681946
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72591}
Turboprop doesn't use optimizations based on field constness to reduce
the number of deoptimizations. While this is safe for loads, for stores
if a different value is stored to a const field we should update the
constness of the field. This is needed so we can safely deopt any other
code that is relying on the constness of the field. Currently, turboprop
doesn't do this. So for now treat stores to constant fields similar to
TurboFan. In future, we may consider adding code to update the field
constness if necessary to reduce the number of deoptimizations.
Bug: chromium:1172797, v8:9684
Change-Id: I1d660457cb5d647e1283a495040a7e452fe1ac7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673401
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72590}
The only opcode which can pop the last control block is "end".
There is already validation in place to check that no code is following
the last "end". Thus all checks for a non-empty control stack in other
opcodes are redundant and can be replaced by DCHECKs.
Drive-by: Avoid the use of {PushControl} for pushing the very first
block, to avoid another check for an empty control stack there.
R=thibaudm@chromium.org
Change-Id: I8f04b225a61f832bca2dd7b706e31d1faa173767
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2678162
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72589}
- Fixes a problem when constructing Wasm CallDescriptors, where the
allocation tries to treat parameters and returns as if they are in the
same frame. This doesn't work when slots may be aligned in their
frame. Instead, allocate parameters and returns separately and offset
return slots by the number of parameter slots.
- Adds argument slot padding in the CallDescriptor lowering case, to
prepare for when 32 bit targets align stack frames and require
padding.
- Adds a regression test.
Bug: chromium:1174500
Change-Id: I60d96a94b171a0d27ff61cbab35623976b0c6da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683024
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72588}
Main changes:
- Introduce a new broker data kind kBackgroundSerialized for objects
that can be serialized in the background (when direct reads are on).
(I'm planning to remove kPossiblyBackgroundSerialized in a followup,
in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
- Make PropertyCell use that new kind.
- Introduce a bottleneck in runtime code for changes to PropertyCells
and make sure that a certain protocol is followed that allows
concurrent reads from the background thread.
- Improve interface of PropertyCell in various ways.
Bug: v8:7790
Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72586}
Those dynamic allocations are responsible for 5-10% of execution time in
wasm code publishing, which again is the biggest contributor to
deserialization time. The allocations are used for patching the jump
table. This CL avoids dynamic memory allocation by having some
thread-local space that is re-used for allocations of
ExternalAssemblerBufferImpl. Since those objects are small, memory usage
is not a concern here.
R=jkummerow@chromium.org
Bug: v8:11164
Cq-Include-Trybots: luci.v8.try:v8_linux64_asan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Change-Id: I44aad86fa821a1ccb59b539da861a346f62a9813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667859
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72585}
WasmCompileLazy needs to save the content of vector
parameter registers. If Simd is not enabled or the hardware
does not support Simd operations then we need to saves the value of
Double registers instead, therefore we need a way to retrieve the
value of "CpuFeatures::SupportsWasmSimd128()" in builtins
during runtime.
Bug: v8:11377
Change-Id: I74a5f870d7077166548472adb25c3fb06d0ebdb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679682
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72584}
This reverts commit da785659be.
Reason for revert: Investigating regressions https://chromeperf.appspot.com/group_report?rev=72572
Original change's description:
> [compiler] Don't serialize JSTypedArray fields
>
> This CL removes serialization of JSTypedArray fields when direct heap
> reads are enabled. Invariants we rely on:
>
> - Of the underlying interesting fields,
> - base_pointer and external_pointer are set either during
> initialization, or in a one-time on-to-off-heap transition in
> GetBuffer.
> - length and buffer are immutable after initialization.
> - is_on_heap and DataPtr derive from base_pointer and
> external_pointer s.t. is_on_heap == (base_pointer != 0) and
> DataPtr == external_pointer in the off-heap case.
>
> In this CL we add one new invariant:
>
> - For all base_pointer and external_pointer mutations after
> initialization, base_pointer is guaranteed to be release-stored
> after external_pointer has been written.
>
> With these invariants, concurrent access to off-heap typed arrays is
> trivial as long as is_on_heap (= base_pointer) is read before other
> relevant fields.
>
> Note that JSTypedArray remains a kSerializedHeapObject due to the
> serialized superclass JSObject.
>
> Drive-by: Remove unused Torque operators and empty TODOs.
>
> Bug: v8:7790
> Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72572}
TBR=neis@chromium.org,jgruber@chromium.org
Change-Id: I5a7e6bacb7b7a3e3510c778837679e6822f26339
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681948
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72583}
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL contains most of the boilerplate code for introducing a new
instance type.
Bug: v8:11388
Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72582}
The interpreter frame is only used for testing now (see linked issue).
This CL removes some remnants in messages.{h,cc}.
R=bmeurer@chromium.org
Bug: v8:10389
Change-Id: I369057ed02dbb68ba40ef9b4aa9a84799d3db528
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681944
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72581}
Bug: v8:11092
Change-Id: I62fe079a67a4643d2e42cbdeabf26b5c7d8bc148
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2677813
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72580}
The detached CppHeap allows for allocation without invoking garbage
collections. Allocated bytes are reported on the first allocation
after the CppHeap has been attached to an Isolate.
States:
- Detached: Allow only allocation;
- Attached: Unified heap GCs;
- Termination GC: Require detached state;
Destruction:
- Heap::TearDown: Detach if attached;
- ~CppHeap: Detach if attached;
Bug: chromium:1056170
Change-Id: I95ce029f36a7f10392257080b6e23e13cc0fc7b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672940
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72579}
This fixes a false positive TSAN report where an object transitions to
a new map in StoreIC. The scenario:
1) Object a transitions from map1 to a newly created map2 in runtime.
The map is installed with a release-store.
2) Object b transitions from map1 to map2 in StoreIC in generated code
that is not visible to TSAN.
3) Concurrent marker visits object b and loads it map with an acquire
load.
Since TSAN does not see the store in step (2) it thinks that the map
loaded in (3) is freshly allocated and is not guarded by a release
store.
Bug: v8:11353
Change-Id: Ifcace9edff987761a4098d3fdfb98c6190f1ee1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682641
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72578}
This adds support for kBool, kInt32, and kUint32 types.
Bug: chromium:1052746
Change-Id: I54641eb036eea30113c44eab2c08626176ecc40a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629463
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72574}
This CL removes serialization of JSTypedArray fields when direct heap
reads are enabled. Invariants we rely on:
- Of the underlying interesting fields,
- base_pointer and external_pointer are set either during
initialization, or in a one-time on-to-off-heap transition in
GetBuffer.
- length and buffer are immutable after initialization.
- is_on_heap and DataPtr derive from base_pointer and
external_pointer s.t. is_on_heap == (base_pointer != 0) and
DataPtr == external_pointer in the off-heap case.
In this CL we add one new invariant:
- For all base_pointer and external_pointer mutations after
initialization, base_pointer is guaranteed to be release-stored
after external_pointer has been written.
With these invariants, concurrent access to off-heap typed arrays is
trivial as long as is_on_heap (= base_pointer) is read before other
relevant fields.
Note that JSTypedArray remains a kSerializedHeapObject due to the
serialized superclass JSObject.
Drive-by: Remove unused Torque operators and empty TODOs.
Bug: v8:7790
Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72572}
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now
represented as objects instead of holding the (primitive) values
directly, and SIMD128 values are no longer represented as Uint8Arrays.
The DWARF extension has been prepared for this breaking change.
The new `WasmValue` comes with `type` and `value` properties that hold
its contents. The motivation here is that this is a more extensible
approach. In case of SIMD128, the `value` property holds the canonical
string representation, which has the additional advantage that these
values can be compared with `===` (and `==`).
This partially reverts https://crrev.com/c/2614428, the main difference
here being that WasmValue is now a proper JSObject that can be exposed
on the DebugEvaluate proxy API.
Screenshot: https://imgur.com/rcahNKM.png
Bug: chromium:1170282, chromium:1071432, chromium:1159402
Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72570}
Those references would be passed over to Blink via buffer and dropped
after a virtual call.
Bug: chromium:1056170
Change-Id: Idd02acce7a2d5c927dd9dc2415fe507b00ff3e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682646
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72568}
Prototype these 6 instructions on arm:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
For all these instructions we rely on having Q registers that map to S
registers, which means we can only use q0 to q7. We fix the src/dst
to q0 arbitrarily.
Bug: v8:11265
Change-Id: Ied95f2dde9859a60fc216ed67615f80e9d795bb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679842
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72567}
Extract i8x16.popcnt implementation into a macro-assembler function, and
reuse it in Liftoff.
Bug: v8:11002
Change-Id: I86b2f5322c799d44f584cac28c70e0e393bf114f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676280
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72565}
