1. 16 Aug, 2021 1 commit
    • Camillo Bruni's avatar
      Revert "[DevTools] Implemented DevTools protocol API to retrieve V8 RunTime Call Stats." · a016cce5
      Camillo Bruni authored
      This reverts commit 91c8be95.
      
      RCS should not be exposed through the API or the inspector protocol as
      they are meant as an internal debugging feature.
      The only regularly tested and supported way is through chrome-tracing.
      
      Given that this was used mostly for an experiment to analyse chrome's
      performance, we can use pprof support as a replacement.
      
      Original change's description:
      > [DevTools] Implemented DevTools protocol API to retrieve V8 RunTime Call Stats.
      >
      > The new APIs are:
      > enableRuntimeCallStats
      > disableRuntimeCallStats
      > getRuntimeCallStats
      >
      > The RunTime Call Stats are collected per isolate.
      >
      > Change-Id: I7e520e2c866288aa9f9dc74f12572abedf0d3ac8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881601
      > Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64784}
      
      Change-Id: Ia7575436e97d3420dd7e68414d89477e6a86bb05
      Bug: v8:11395
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998585Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76297}
      a016cce5
  2. 27 May, 2021 1 commit
  3. 18 Nov, 2020 1 commit
  4. 08 Sep, 2020 1 commit
  5. 17 Aug, 2020 1 commit
  6. 12 Feb, 2020 1 commit
    • Sigurd Schneider's avatar
      [coverage] Provide option to prevent triggered updates · 117520e2
      Sigurd Schneider authored
      Coverage updates are sent as deltas, and this means that it
      is very important that the consumer gets /all/ updates;
      otherwise, the coverage information will be wrong.
      
      Previously, we introduces the ability into the back-end to
      send triggered updates, i.e. updates that are triggered by
      the back-end at interesting points in time. These updates
      are delivered via an event, and any consumer must process
      these events.
      
      This CL introduces a flag to startPreciseCoverage that
      controls whether the back-end is allowed to send such
      triggered updates on its own initiative. The default is
      `false` to maintain backwards compatibility with consumers
      that don't yet handle the events.
      
      Bug: chromium:1022031
      Change-Id: Ie36a92a3b627b19ea4041f1b8da1ec66c6b9b771
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043798Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66232}
      117520e2
  7. 20 Jan, 2020 1 commit
    • Sigurd Schneider's avatar
      [coverage] Add event for coverage reporting · ee8602d3
      Sigurd Schneider authored
      This CL adds a new event that enables the back-end to send coverage
      updates on its own initiative. This event can be triggered via the C++
      method `triggerPreciseCoverageDeltaUpdate` on the agent in a way that
      causes coverage data to be immediatelly collected.
      
      This is useful in the back-end to collect coverage at a certain point
      in time, i.e. when a lifecycle event such as first contentful paint
      occurs.
      
      The previous interface could not support this, because it could not
      reasonably be triggered from C++, and if triggered through the protocol,
      dispatching messages added delay that invalidated the data (i.e. data
      might have been taken too late to be accurate).
      
      TBR=yangguo@chromium.org
      
      Change-Id: I0f7201412a8d64866e6e314e5bc850354c13a9da
      Bug: chromium:1022031
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992437
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65864}
      ee8602d3
  8. 10 Jan, 2020 1 commit
  9. 05 Nov, 2019 1 commit
  10. 13 Sep, 2019 1 commit
  11. 07 Mar, 2018 1 commit
  12. 02 Feb, 2018 1 commit
  13. 08 Sep, 2017 1 commit
  14. 23 Aug, 2017 1 commit
  15. 23 Mar, 2017 1 commit
    • yangguo's avatar
      [debug] introduce precise binary code coverage. · d71ef941
      yangguo authored
      With precise binary code coverage, the reported count is either 0 or 1.
      We only report 1 the first time we collect coverage data after the
      function has been executed.
      
      Since we do not care about the accurate execution count, we can optimize
      the function once it has been executed once.
      
      Also change best effort coverage to be implicitly binary.
      
      R=caseq@chromium.org, jgruber@chromium.org, pfeldman@chromium.org
      BUG=v8:5808
      
      Review-Url: https://codereview.chromium.org/2766573003
      Cr-Commit-Position: refs/heads/master@{#44074}
      d71ef941
  16. 25 Feb, 2017 1 commit
  17. 16 Nov, 2016 1 commit
  18. 02 Nov, 2016 1 commit
  19. 26 Sep, 2016 1 commit
  20. 21 Sep, 2016 2 commits
  21. 19 Sep, 2016 1 commit
  22. 09 Sep, 2016 1 commit
  23. 01 Sep, 2016 1 commit
  24. 31 Aug, 2016 2 commits