Skip to content

V
V8
Switch branch/tag
  1. 07 May, 2019 1 commit
  3. 17 Apr, 2019 2 commits
    • Clemens Hammacher's avatar
      Reland "[wasm] Add stack guard for logging code" · 48635511
      Clemens Hammacher authored 
      This is a reland of 067ba2a0.
Unchanged reland, hence TBR.

Original change's description:
> [wasm] Add stack guard for logging code
>
> Benchmarks or worker threads might never return to the event queue,
> hence they will never execute the scheduled foreground task to log
> compiled and published wasm code.
> This CL adds a stack guard to log the code, to ensure that we also log
> it for wasm code that never returns to the event queue.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9104
> Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60879}

TBR=mstarzinger@chromium.org

Bug: v8:9104
Change-Id: I105b37ef8429d16ef5b983919ba8bca615e347c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570017Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60899}
      48635511
    • Michael Hablich's avatar
      Revert "[wasm] Add stack guard for logging code" · 6ce63fd8
      Michael Hablich authored 
      This reverts commit 067ba2a0.

Reason for revert: blocks roll: https://chromium-review.googlesource.com/c/chromium/src/+/1570208

21:26:22.251 27507   # Fatal error in ../../v8/src/profiler/profile-generator.cc, line 19
21:26:22.251 27507   # Debug check failed: line > 0 (0 vs. 0).
21:26:22.251 27507   #
21:26:22.251 27507   #
21:26:22.251 27507   #
21:26:22.252 27507   #FailureMessage Object: 0x7ffe851046a0#0 0x56532cb371f9 base::debug::CollectStackTrace()
21:26:22.252 27507   #1 0x56532ca70863 base::debug::StackTrace::StackTrace()
21:26:22.252 27507   #2 0x56532e99610b gin::(anonymous namespace)::PrintStackTrace()
21:26:22.252 27507   #3 0x56532e989468 V8_Fatal()
21:26:22.252 27507   #4 0x56532e9891c5 v8::base::(anonymous namespace)::DefaultDcheckHandler()
21:26:22.252 27507   #5 0x56532b2bb876 v8::internal::SourcePositionTable::SetPosition()
21:26:22.252 27507   #6 0x56532b2c2268 v8::internal::ProfilerListener::CodeCreateEvent()
21:26:22.252 27507   #7 0x56532ae25275 v8::internal::(anonymous namespace)::LogFunctionCompilation()
21:26:22.252 27507   #8 0x56532ae26008 v8::internal::OptimizedCompilationJob::RecordFunctionCompilation()
21:26:22.252 27507   #9 0x56532ae32a08 v8::internal::Compiler::FinalizeOptimizedCompilationJob()
21:26:22.252 27507   #10 0x56532ae228eb v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions()
21:26:22.252 27507   #11 0x56532af14e4a v8::internal::StackGuard::HandleInterrupts()
21:26:22.252 27507   #12 0x56532b35f2ec v8::internal::__RT_impl_Runtime_StackGuard()
21:26:22.252 27507   #13 0x56532bba6720 <unknown>

Original change's description:
> [wasm] Add stack guard for logging code
> 
> Benchmarks or worker threads might never return to the event queue,
> hence they will never execute the scheduled foreground task to log
> compiled and published wasm code.
> This CL adds a stack guard to log the code, to ensure that we also log
> it for wasm code that never returns to the event queue.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: v8:9104
> Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60879}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: I63dc56a41747caf683b14869a2d62017fd0301c1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9104
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570012Reviewed-by: 's avatarMichael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60890}
      6ce63fd8
  5. 16 Apr, 2019 1 commit
  7. 04 Apr, 2019 1 commit
  9. 06 Mar, 2019 3 commits
    • Deepti Gandluri's avatar
      Reland "[wasm] Lazy update instances on a shared Memory.Grow" · 365b637c
      Deepti Gandluri authored 
      This is a reland of 80f06d6f

Original change's description:
> [wasm] Lazy update instances on a shared Memory.Grow
> 
>  - Introduce a GROW_SHARED_MEMORY interrupt, and handler
>  - Memory objects for isolates are updated on a stack check, add
>    tracking for isolates that hit the stack check
>  - When enough memory is not reserved ahead of time, fail to grow
>  - Add tracking for externalized buffers in the MemoryTracker so
>    that the MemoryTracker will know when backing_stores can be freed.
>  - For shared buffer, do not always allocate a new buffer when
>    growing an externalized buffer
> 
> 
> Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
> Bug: v8:8564
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60064}

Bug: v8:8564
Change-Id: Id0cf8e42a9d54ac702dba351e248a1b92713c98a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1506357Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60071}
      365b637c
    • Bill Budge's avatar
      Revert "[wasm] Lazy update instances on a shared Memory.Grow" · e15bb0b3
      Bill Budge authored 
      This reverts commit 80f06d6f.

Reason for revert: failing grow-memory tests

Original change's description:
> [wasm] Lazy update instances on a shared Memory.Grow
> 
>  - Introduce a GROW_SHARED_MEMORY interrupt, and handler
>  - Memory objects for isolates are updated on a stack check, add
>    tracking for isolates that hit the stack check
>  - When enough memory is not reserved ahead of time, fail to grow
>  - Add tracking for externalized buffers in the MemoryTracker so
>    that the MemoryTracker will know when backing_stores can be freed.
>  - For shared buffer, do not always allocate a new buffer when
>    growing an externalized buffer
> 
> 
> Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
> Bug: v8:8564
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60064}

TBR=binji@chromium.org,titzer@chromium.org,gdeepti@chromium.org,ahaas@chromium.org

Change-Id: I2ed0b59bcbb285b701172b401d606963261d375c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1506355Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60068}
      e15bb0b3
    • Deepti Gandluri's avatar
      [wasm] Lazy update instances on a shared Memory.Grow · 80f06d6f
      Deepti Gandluri authored 
       - Introduce a GROW_SHARED_MEMORY interrupt, and handler
 - Memory objects for isolates are updated on a stack check, add
   tracking for isolates that hit the stack check
 - When enough memory is not reserved ahead of time, fail to grow
 - Add tracking for externalized buffers in the MemoryTracker so
   that the MemoryTracker will know when backing_stores can be freed.
 - For shared buffer, do not always allocate a new buffer when
   growing an externalized buffer


Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
Bug: v8:8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarBen Smith <binji@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60064}
      80f06d6f
  11. 26 Dec, 2018 1 commit
  13. 18 Dec, 2018 1 commit
  15. 11 Dec, 2018 1 commit
  17. 29 Oct, 2018 1 commit
  19. 30 May, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] use interrupt for pause only as last resort · 6d87d957
      Alexey Kozyatinskiy authored 
      With this CL we use interrupt for pause in two cases:
- when we process Debugger.pause on interruption,
- when we would like to break as soon as possible after OOM.
In all other cases, e.g. for async step into we use break
on function call by calling StepIn debugger action.

In mentioned cases we should not actually use interrupt as well:
- Debugger.pause in this case scheduled using interrupt and we
  may just break right now without requesting another interrupt,
  unfortunately blink side is not ready,
- we should use more reliable way to break right after near OOM
  callback, otherwise we can get this callback, increase limit,
  request break on next interrupt, before interrupt get another
  huge memory allocation and crash.

There are couple advantages:
- we get much better break locations for async stepping
  (see inspector tests expectations),
- we can remove DEBUG_BREAK interruption
  (it should speedup blackboxing with async tasks, see
  removed todo in debug.cc for details)
- it is required preparation step for async step out,
  (see https://chromium-review.googlesource.com/c/v8/v8/+/1054618)

Bug: v8:7753
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iabd7627dbffa9a0eab1736064caf589d02591926
Reviewed-on: https://chromium-review.googlesource.com/1054155
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53439}
      6d87d957
  21. 04 May, 2018 1 commit
  23. 23 Apr, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [runtime] implemented SafeForInterruptsScope · d3f6c647
      Alexey Kozyatinskiy authored 
      This CL introduced SafeForInterruptsScope. This scope overrides
outer PostponeInterruptsScopes:
- reschedule postponed interrupts if needed,
- allow requesting new interrupts.
As soon as scope removed interrupts are posponed if needed.

This scope will be:
- used to allow inspector to interrupt and terminate
  DebugeEvaluate::Local,
- exposed with new flag on Isolate to implement SafeForTerminationScope
  in blink.

R=yangguo@chromium.org

Bug: chromium:820640
Change-Id: I15befc10c2cee393d1e3be48cecb31ee14dae638
Reviewed-on: https://chromium-review.googlesource.com/1022969
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52743}
      d3f6c647
  25. 09 Apr, 2018 1 commit
  27. 26 Feb, 2018 1 commit
  29. 09 Jan, 2018 1 commit
  31. 04 Dec, 2017 1 commit
    • Caitlin Potter's avatar
      [builtins] implement RunMicrotasks pump as a code stub · 52ff3ae4
      Caitlin Potter authored 
      - Implement RunMicrotasks in CSA to prevent a potentially large number
  of jumps between C++ and JS code while consuming te queue. Appears to
  provide a ~60% speedup in microtask-heavy code, which from limited
  testing appears to scale linearly.

  The code-stub microtask pump bails out to the old C++ microtask pump
  if it encounters a CallHandlerInfo microtask, and remains in C++ for
  the remainder of the queue (returning to the JS/stub implementation
  after the bailed out queue is exhausted).

- Add a variation of JSEntryStub which enters the new RunMicrotasks code
  stub.

- Add a new RunMicrotasks helper to Execution, which uses the
  RunMicrotasks entry stub.

Bug: 
Change-Id: I4667d4dd633d24455ea5d7cef239da0af1a7365e
Reviewed-on: https://chromium-review.googlesource.com/650486
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49842}
      52ff3ae4
  33. 01 Dec, 2017 1 commit
  35. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback
vector to store an optimization marker (optimize/in optimization queue)
rather than changing the JSFunction's code object. Then, adapt the
self-healing mechanism to also dispatch based on this optimization
marker. Similarly, replace SFI marking with optimization marker checks
in CompileLazy.

This allows JSFunctions to share optimization information (replacing
shared function marking) without leaking this information across native
contexts. Non I+TF functions (asm.js or --no-turbo) use a
CheckOptimizationMarker shim which generalises the old
CompileOptimized/InOptimizationQueue builtins and also checks the same
optimization marker as CompileLazy and InterpreterEntryTrampoline.

This is a reland of https://chromium-review.googlesource.com/c/509716

Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  37. 13 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored 
      This reverts commit e39c9e02.

Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561

Original change's description:
> [compiler] Drive optimizations with feedback vector
> 
> For interpreted functions, use the optimized code slot in the feedback vector
> to store an optimization marker (optimize/in optimization queue) rather than
> changing the JSFunction's code object. Then, adapt the self-healing mechanism
> to also dispatch based on this optimization marker. Similarly, replace SFI
> marking with optimization marker checks in CompileLazy.
> 
> This allows JSFunctions to share optimization information (replacing shared
> function marking) without leaking this information across native contexts. Non
> I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
> generalises the old CompileOptimized/InOptimizationQueue builtins and also
> checks the same optimization marker as CompileLazy and
> InterpreterEntryTrampoline.
> 
> Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
> Reviewed-on: https://chromium-review.googlesource.com/509716
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45901}

TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true

Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback vector
to store an optimization marker (optimize/in optimization queue) rather than
changing the JSFunction's code object. Then, adapt the self-healing mechanism
to also dispatch based on this optimization marker. Similarly, replace SFI
marking with optimization marker checks in CompileLazy.

This allows JSFunctions to share optimization information (replacing shared
function marking) without leaking this information across native contexts. Non
I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
generalises the old CompileOptimized/InOptimizationQueue builtins and also
checks the same optimization marker as CompileLazy and
InterpreterEntryTrampoline.

Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
Reviewed-on: https://chromium-review.googlesource.com/509716
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
  39. 30 May, 2017 1 commit
  41. 26 May, 2017 1 commit
  43. 08 Feb, 2017 1 commit
  45. 27 Jan, 2017 1 commit
  47. 23 Jan, 2017 1 commit
  49. 20 Jan, 2017 2 commits
  51. 17 Jan, 2017 1 commit
  53. 01 Dec, 2016 1 commit
  55. 24 Nov, 2016 1 commit
  57. 26 Sep, 2016 1 commit
    • jgruber's avatar
      Enable component builds for fuzzers · 22606f0c
      jgruber authored 
      V8 is collecting a growing amount of fuzzers, all of which take substantial
space on the bots and in chromium build archives. This CL improves that
situation by allowing component (shared library) builds for almost all fuzzers.

The parser fuzzer is handled as an exception since it would require exporting a
large number of additional functions.

A component build results in about a 50-100x improvement in file size for each
fuzzer (~50M-100M to around 1.1M).

BUG=chromium:648864
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe

Review-Url: https://codereview.chromium.org/2360983002
Cr-Commit-Position: refs/heads/master@{#39709}
      22606f0c
  59. 30 Aug, 2016 1 commit
    • jgruber's avatar
      Refactor call site handling for stack formatting · f7bc1fc7
      jgruber authored 
      This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=

Review-Url: https://codereview.chromium.org/2275233002
Cr-Commit-Position: refs/heads/master@{#39015}
      f7bc1fc7
  61. 18 Aug, 2016 1 commit
    • jgruber's avatar
      Revert of Use a custom Struct for stack trace storage (patchset #4 id:60001 of... · 6b7493a4
      jgruber authored 
      Revert of Use a custom Struct for stack trace storage (patchset #4 id:60001 of https://codereview.chromium.org/2230953002/ )

Reason for revert:
Performance regressions in Gameboy, Life, CodeLoad and others. See crbug.com/638210.

Original issue's description:
> Refactor data structures for simple stack traces
>
> Simple stack traces are captured through Isolate::CaptureSimpleStackTrace.
> Captured frames are stored in a FixedArray, which in turn is stored as a
> property (using a private symbol) on the error object itself. Actual formatting
> of the textual stack trace is done lazily when the user reads the stack
> property of the error object.
>
> This would involve many conversions back and forth between index-encoded raw
> data (receiver, function, offset and code), JS CallSite objects, and C++
> CallSite objects.
>
> This commit refactors the C++ CallSite class into a Struct class called
> StackTraceFrame, which is the new single point of truth frame information.
> Isolate::CaptureSimpleStackTrace stores an array of StackTraceFrames, and JS
> CallSite objects (now created only when the user specifies custom stack trace
> formatting through Error.prepareStackTrace) internally only store a reference
> to a StackTraceFrame.
>
> BUG=
>
> Committed: https://crrev.com/b4c1aefb9c369f1a33a6ca94a5de9b06ea4bf5c4
> Cr-Commit-Position: refs/heads/master@{#38645}

TBR=yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

Review-Url: https://codereview.chromium.org/2252783007
Cr-Commit-Position: refs/heads/master@{#38700}
      6b7493a4
  63. 16 Aug, 2016 1 commit
    • jgruber's avatar
      Refactor data structures for simple stack traces · b4c1aefb
      jgruber authored 
      Simple stack traces are captured through Isolate::CaptureSimpleStackTrace.
Captured frames are stored in a FixedArray, which in turn is stored as a
property (using a private symbol) on the error object itself. Actual formatting
of the textual stack trace is done lazily when the user reads the stack
property of the error object.

This would involve many conversions back and forth between index-encoded raw
data (receiver, function, offset and code), JS CallSite objects, and C++
CallSite objects.

This commit refactors the C++ CallSite class into a Struct class called
StackTraceFrame, which is the new single point of truth frame information.
Isolate::CaptureSimpleStackTrace stores an array of StackTraceFrames, and JS
CallSite objects (now created only when the user specifies custom stack trace
formatting through Error.prepareStackTrace) internally only store a reference
to a StackTraceFrame.

BUG=

Review-Url: https://codereview.chromium.org/2230953002
Cr-Commit-Position: refs/heads/master@{#38645}
      b4c1aefb
  65. 15 Jan, 2016 1 commit
  67. 08 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Object.keys to C++. · 50e1e751
      bmeurer authored 
      Everything necessary to implement Object.keys efficiently is already
available in C++ land for quite some time now, and only the thin
JavaScript wrapper was left, so get rid of that as well and move the
whole builtin to C++ instead.

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1567963002

Cr-Commit-Position: refs/heads/master@{#33167}
      50e1e751
  69. 05 Jan, 2016 1 commit
    • bmeurer's avatar
      [runtime] Migrate several Date builtins to C++. · 065e9c53
      bmeurer authored 
      Almost all of the Date builtins always call into C++ at least once
anyway, so parsing, compiling and executing the JavaScript wrappers
is just a waste of time.  The most important part here is the Date
constructor itself, which is one of the blockers for new.target in
TurboFan, because compiling the Date constructor takes too much time
with TurboFan (for no reason since we end up in C++ anway).

R=cbruni@chromium.org

Review URL: https://codereview.chromium.org/1556333002

Cr-Commit-Position: refs/heads/master@{#33109}
      065e9c53