1. 17 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm][gc] Track number of GCs triggered per module · 429ee454
      Clemens Hammacher authored
      We currently have the problem that we trigger too many code GCs since
      {new_potentially_dead_code_size_} is never reset to zero.
      This CL adds a counter which tells us how many GCs we ran per native
      module. This counter is sampled on each code GC. It will give us a
      good understanding of the amount of GC work we are executing in the
      wild. The number should stay in the single-digits generally.
      
      R=mstarzinger@chromium.org, mpearson@chromium.org
      
      Bug: v8:8217
      Change-Id: I978a98dff76e0f466ff51e067626886b58d52ded
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615246Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61611}
      429ee454
  2. 07 May, 2019 2 commits
  3. 03 May, 2019 2 commits
  4. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm][gc] Fix infinite GC loop · ac497d1c
      Clemens Hammacher authored
      One fundamental assumption of the wasm code GC is that code becomes
      "potentially dead" at most once; if the ref counts drops to zero later,
      it should be freed for real.
      In the current implementation, it happens that code becomes potentially
      dead, then becomes dead for real (it's removed from the set of
      potentially dead code), and then we remove the last reference. At that
      point, we re-add the code to the potentially dead code, considering it
      for garbage collection again. This can lead to an endless loop.
      
      This CL fixes that by remembering which code was already detected as
      dead, and does not consider this code for another GC.
      This requires freeing code via the {WasmEngine} such that the set of
      dead code can be cleaned up.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8217
      Change-Id: If6a95a7918db2ad82edfad5447c536593243db7d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585845Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61073}
      ac497d1c
  5. 16 Apr, 2019 1 commit
  6. 09 Apr, 2019 2 commits
  7. 13 Mar, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Keep NativeModule alive in BackgroundCompileScope · 3df442d7
      Clemens Hammacher authored
      We need to ensure that the NativeModule stays alive while any
      {BackgroundCompileScope} exists, because during that time we hold
      shared ownership of the mutex in the {BackgroundCompileToken}. If the
      {NativeModule} dies during that period, we would need to get exclusive
      ownership of the mutex and deadlock.
      
      This change requires holding a {std::weak_ptr<NativeModule>} in the
      BackgroundCompileToken instead of a raw pointer, hence it can only be
      initialized after the NativeModule was created. This is done via a
      separate {InitCompilationState} method.
      
      R=ahaas@chromium.org
      
      Bug: v8:8979
      Change-Id: Ia14bd272ea0bc47aec547024da6020608418c9d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518178
      Auto-Submit: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60203}
      3df442d7
  8. 11 Mar, 2019 1 commit
  9. 06 Feb, 2019 1 commit
  10. 01 Feb, 2019 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Remove finisher task" · 84f17076
      Clemens Hammacher authored
      This is a reland of ac2fb66b.
      Crashes were fixed in https://crrev.com/c/1429862.
      
      Original change's description:
      > [wasm] Remove finisher task
      >
      > This removes the finisher task and instead finishes compilation units
      > from the background.
      > It also changes ownership of the AsyncCompileJob to be shared among all
      > tasks that still operate on it. The AsyncCompileJob dies when the last
      > reference dies.
      >
      > R=ahaas@chromium.org
      > CC=​​mstarzinger@chromium.org
      >
      > Bug: v8:7921, v8:8423
      > Change-Id: Id09378327dfc146459ef41bc97176a8716756ae4
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/1335553
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58630}
      
      Bug: v8:7921, v8:8423
      Change-Id: I3dcee4e8e56d2a524d302af91b5cb4a7a9ceb8ce
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1400781
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59302}
      84f17076
  11. 25 Jan, 2019 2 commits
    • Clemens Hammacher's avatar
      [wasm] Move code logging to the WasmEngine · 0c25403c
      Clemens Hammacher authored
      The compilation state should have no notion of Isolates. Move code
      logging and management of the corresponding foreground task to the
      WasmEngine.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8689
      Change-Id: Ib690317139d0754731b9f0e71d06e7a722082eed
      Reviewed-on: https://chromium-review.googlesource.com/c/1434035
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59093}
      0c25403c
    • Clemens Hammacher's avatar
      [wasm] Move Isolate management to WasmEngine · a1ff298d
      Clemens Hammacher authored
      The WasmCodeManager held a list of all Isolates that use the
      WasmEngine/WasmCodeManager (those two are 1:1).
      Since we want to move all isolate-specific tasks (like code logging and
      compilation callbacks) to the WasmEngine, this CL moves this management
      from the WasmCodeManager to the WasmEngine. We now have a bidirectional
      mapping from NativeModules to the Isolates that use them, and from an
      Isolate to all the NativeModules it uses (n:n).
      The IsolateData struct will be extended in follow-up CLs to hold things
      like the ForegroundTaskRunner. The Isolate* in the NativeModule /
      CompilationState will eventually be removed.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8689
      Change-Id: Ic2c003c3949f73ce3264dd9dac96884a5c0b9896
      Reviewed-on: https://chromium-review.googlesource.com/c/1433793
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59092}
      a1ff298d
  12. 23 Jan, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[wasm] Decouple background compile jobs from NativeModule" · eab3508a
      Clemens Hammacher authored
      This is a reland of 92d9b09c.
      Patch unchanged, errors fixed by https://crrev.com/c/1430059.
      
      Original change's description:
      > [wasm] Decouple background compile jobs from NativeModule
      >
      > Background compile jobs should not keep the NativeModule alive, for two
      > reasons:
      > 1) We sometimes have to wait for background compilation to finish (from
      >    a foreground task!). This introduces unnecessary latency.
      > 2) Giving the background compile tasks shared ownership of the
      >    NativeModule causes the NativeModule (and the CompilationState) to
      >    be freed from background tasks, which is error-prone (see
      >    https://crrev.com/c/1400420).
      >
      > Instead, this CL introduces a BackgroundCompileToken which is held
      > alive by the NativeModule and all background compile jobs. The initial
      > and the final phase of compilation (getting and submitting work)
      > synchronize on this token to check and ensure that the NativeModule is
      > and stays alive. During compilation itself, the mutex is released, such
      > that the NativeModule can die.
      > The destructor of the NativeModule cancels the BackgroundCompileToken.
      > Immediately afterwards, the NativeModule and the CompilationState can
      > die.
      >
      > This change allows to remove two hacks introduced previously: The atomic
      > {aborted_} flag and the {FreeCallbacksTask}.
      >
      > R=mstarzinger@chromium.org
      > CC=titzer@chromium.org
      >
      > Bug: v8:8689, v8:7921
      > Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/1421364
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59020}
      
      TBR=mstarzinger@chromium.org
      
      Bug: v8:8689, v8:7921
      Change-Id: Iead972ef77c8503da7246cab48e7693b176d8f02
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1429862Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59035}
      eab3508a
    • Clemens Hammacher's avatar
      Revert "[wasm] Decouple background compile jobs from NativeModule" · ea513ab8
      Clemens Hammacher authored
      This reverts commit 92d9b09c.
      
      Reason for revert: Crashes on several bots, e.g. https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20UBSan/4237
      
      Original change's description:
      > [wasm] Decouple background compile jobs from NativeModule
      > 
      > Background compile jobs should not keep the NativeModule alive, for two
      > reasons:
      > 1) We sometimes have to wait for background compilation to finish (from
      >    a foreground task!). This introduces unnecessary latency.
      > 2) Giving the background compile tasks shared ownership of the
      >    NativeModule causes the NativeModule (and the CompilationState) to
      >    be freed from background tasks, which is error-prone (see
      >    https://crrev.com/c/1400420).
      > 
      > Instead, this CL introduces a BackgroundCompileToken which is held
      > alive by the NativeModule and all background compile jobs. The initial
      > and the final phase of compilation (getting and submitting work)
      > synchronize on this token to check and ensure that the NativeModule is
      > and stays alive. During compilation itself, the mutex is released, such
      > that the NativeModule can die.
      > The destructor of the NativeModule cancels the BackgroundCompileToken.
      > Immediately afterwards, the NativeModule and the CompilationState can
      > die.
      > 
      > This change allows to remove two hacks introduced previously: The atomic
      > {aborted_} flag and the {FreeCallbacksTask}.
      > 
      > R=​mstarzinger@chromium.org
      > CC=​titzer@chromium.org
      > 
      > Bug: v8:8689, v8:7921
      > Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/1421364
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59020}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: I724f460f5aa654a9e75d3ce73d351214e69e2d96
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8689, v8:7921
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1429861Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59022}
      ea513ab8
    • Clemens Hammacher's avatar
      [wasm] Decouple background compile jobs from NativeModule · 92d9b09c
      Clemens Hammacher authored
      Background compile jobs should not keep the NativeModule alive, for two
      reasons:
      1) We sometimes have to wait for background compilation to finish (from
         a foreground task!). This introduces unnecessary latency.
      2) Giving the background compile tasks shared ownership of the
         NativeModule causes the NativeModule (and the CompilationState) to
         be freed from background tasks, which is error-prone (see
         https://crrev.com/c/1400420).
      
      Instead, this CL introduces a BackgroundCompileToken which is held
      alive by the NativeModule and all background compile jobs. The initial
      and the final phase of compilation (getting and submitting work)
      synchronize on this token to check and ensure that the NativeModule is
      and stays alive. During compilation itself, the mutex is released, such
      that the NativeModule can die.
      The destructor of the NativeModule cancels the BackgroundCompileToken.
      Immediately afterwards, the NativeModule and the CompilationState can
      die.
      
      This change allows to remove two hacks introduced previously: The atomic
      {aborted_} flag and the {FreeCallbacksTask}.
      
      R=mstarzinger@chromium.org
      CC=titzer@chromium.org
      
      Bug: v8:8689, v8:7921
      Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1421364
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59020}
      92d9b09c
  13. 08 Jan, 2019 2 commits
  14. 26 Dec, 2018 1 commit
  15. 12 Dec, 2018 1 commit
  16. 21 Nov, 2018 1 commit
    • Ross McIlroy's avatar
      [AsmJs] Avoid allocation of WasmModuleObject until instantiation. · ccd8073c
      Ross McIlroy authored
      Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
      since that is called when we are compiling the native context independent SharedFunctionInfo
      and the WasmModuleObject requires a native context. Instead save the members required to
      create the object in the AsmWasmData and create it during module instantiation. Note:
      since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
      this doeesn't have semantic change for asm.js code.
      
      As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
      struct. Some logic is also moved from module-compiler to wasm-engine to make the
      seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
      
      BUG=chromium:900535,v8:8395
      
      Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
      Reviewed-on: https://chromium-review.googlesource.com/c/1345509
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57704}
      ccd8073c
  17. 30 Oct, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Store compile errors in CompilationState" · 1ff80455
      Clemens Hammacher authored
      This is a reland of bf3d7b9a
      
      Original change's description:
      > [wasm] Store compile errors in CompilationState
      > 
      > We are currently storing compilation errors in the individual
      > compilation units and pass it to the ErrorThrower during finishing.
      > This CL changes that to store errors on the CompilationState directly.
      > From there, it is propagated to the ErrorThrower in the compilation
      > state callback.
      > This removes more work from the finisher task and slims down the
      > WasmCompilationUnits.
      > 
      > R=mstarzinger@chromium.org
      > 
      > Bug: v8:8343, v8:7921
      > Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
      > Reviewed-on: https://chromium-review.googlesource.com/c/1303720
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57091}
      
      Bug: v8:8343, v8:7921
      Change-Id: Iaa5c89d224cb2bcfca2d12eba305413a9ad95618
      Reviewed-on: https://chromium-review.googlesource.com/c/1304547
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57126}
      1ff80455
  18. 29 Oct, 2018 2 commits
    • Maya Lekova's avatar
      Revert "[wasm] Store compile errors in CompilationState" · dd5c3631
      Maya Lekova authored
      This reverts commit bf3d7b9a.
      
      Reason for revert: Breaks TSAN build, see
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/23248
      
      Original change's description:
      > [wasm] Store compile errors in CompilationState
      > 
      > We are currently storing compilation errors in the individual
      > compilation units and pass it to the ErrorThrower during finishing.
      > This CL changes that to store errors on the CompilationState directly.
      > From there, it is propagated to the ErrorThrower in the compilation
      > state callback.
      > This removes more work from the finisher task and slims down the
      > WasmCompilationUnits.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:8343, v8:7921
      > Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
      > Reviewed-on: https://chromium-review.googlesource.com/c/1303720
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57091}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: Id32c7337494a4749485adbcfcaae7b2331afea66
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8343, v8:7921
      Reviewed-on: https://chromium-review.googlesource.com/c/1304544Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57094}
      dd5c3631
    • Clemens Hammacher's avatar
      [wasm] Store compile errors in CompilationState · bf3d7b9a
      Clemens Hammacher authored
      We are currently storing compilation errors in the individual
      compilation units and pass it to the ErrorThrower during finishing.
      This CL changes that to store errors on the CompilationState directly.
      From there, it is propagated to the ErrorThrower in the compilation
      state callback.
      This removes more work from the finisher task and slims down the
      WasmCompilationUnits.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8343, v8:7921
      Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
      Reviewed-on: https://chromium-review.googlesource.com/c/1303720Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57091}
      bf3d7b9a
  19. 23 Oct, 2018 1 commit
  20. 25 Sep, 2018 1 commit
  21. 18 Sep, 2018 1 commit
  22. 13 Sep, 2018 1 commit
  23. 07 Sep, 2018 2 commits
  24. 21 Aug, 2018 1 commit
  25. 17 Aug, 2018 1 commit
  26. 14 Aug, 2018 1 commit
    • Andreas Haas's avatar
      Reland "[wasm] Implement the new API for WebAssembly.instantiateStreaming" · 3e545e40
      Andreas Haas authored
      The problem was that in AsyncCompileJob::FinishModule we allocate a
      handle, but when this function is called from streaming compilation, then
      there was no HandleScope around AsyncCompileJob::FinishModule. This issue
      was fixed in another CL, https://crrev.com/c/1172357. This CL is just a
      rebase of the original CL.
      
      Original change's description:
      > [wasm] Implement the new API for WebAssembly.instantiateStreaming
      
      > This is the second V8 CL to refactor WebAssembly.instantiateStreaming to
      > make it spec compliant again. The design doc where the whole change is
      > discussed is available in the tracking bug. The tracking bug also
      > references prototype implementations of the whole change, which includes
      > the changes in this CL.
      
      R=starzinger@chromium.org
      
      Bug: chromium:860637
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: Ib0cb25488654d2b325b4f529d33b76b846c64436
      Reviewed-on: https://chromium-review.googlesource.com/1172429Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55106}
      3e545e40
  27. 13 Aug, 2018 1 commit
  28. 09 Aug, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Add WasmFeatures to enable/detect features · 6aa2a253
      Ben L. Titzer authored
      This CL introduces a set of configuration options implemented as
      a struct of booleans that together comprise the set of enabled
      or detected features. The configuration options replace command-line
      flags that were checked deep in the implementation. As such, it is
      necessary to plumb them through multiple levels of abstraction.
      
      R=ahaas@chromium.org
      CC=mstarzinger@chromium.org
      BUG=chromium:868844
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
      Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55018}
      6aa2a253
  29. 02 Aug, 2018 1 commit
    • Andreas Haas's avatar
      Revert "[wasm] Implement the new API for WebAssembly.instantiateStreaming" · fea9300d
      Andreas Haas authored
      This reverts commit b556c9ea.
      
      Reason for revert: Flakes in layout tests: https://crbug.com/870187
      
      Original change's description:
      > [wasm] Implement the new API for WebAssembly.instantiateStreaming
      > 
      > This is the second V8 CL to refactor WebAssembly.instantiateStreaming to
      > make it spec compliant again. The design doc where the whole change is
      > discussed is available in the tracking bug. The tracking bug also
      > references prototype implementations of the whole change, which includes
      > the changes in this CL.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: chromium:860637
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      > Change-Id: I776c0f24959ab5663727d3dfee0248a9b0642a42
      > Reviewed-on: https://chromium-review.googlesource.com/1143187
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54834}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:860637
      Change-Id: Icbf2603143068a49c61de162aa7185a753703e5d
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1160261Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54872}
      fea9300d
  30. 01 Aug, 2018 2 commits