1. 12 Jun, 2019 1 commit
    • Benedikt Meurer's avatar
      [counters] Introduce proper bottleneck for FunctionCallback. · ea420655
      Benedikt Meurer authored
      API calls made via the CallApiCallback builtin, which is used from the
      ICs and optimized code, are currently misattributed to the wrong counter
      InvokeFunctionCallback instead of FunctionCallback. In addition we don't
      use the C trampoline when only runtime call stats are enabled, but the
      Chrome DevTools profiler is not active, which means that these calls
      will not be attrituted properly at all, and that had to be worked around
      using all kinds of tricks (i.e. disabling fast-paths in ICs when RCS is
      active and not inlining calls/property accesses into optimized code
      depending on the state of RCS).
      
      All of this was really brittle and only due to the fact that the central
      builtin didn't properly check for RCS (in addition to checking for the
      CDT profiler). With this fix it's now handled in a central place and
      attributed to the correct category, so user code doesn't need to worry
      about RCS anymore and can just call straight into the fast-path.
      
      Drive-by-fix: Do the same for AccessorInfo getter calls, which share the
      core hand-written native code with the API callback logic.
      
      Bug: v8:9183
      Change-Id: Id0cd99d3dd676635fe3272b67cd76a19a9a9cea4
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1651470
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62109}
      ea420655
  2. 27 May, 2019 1 commit
  3. 23 May, 2019 2 commits
  4. 20 May, 2019 1 commit
  5. 17 May, 2019 3 commits
  6. 16 May, 2019 2 commits
  7. 08 Apr, 2019 1 commit
  8. 28 Mar, 2019 2 commits
  9. 27 Mar, 2019 1 commit
  10. 07 Mar, 2019 1 commit
  11. 17 Sep, 2018 1 commit
  12. 14 Sep, 2018 1 commit
  13. 15 Aug, 2018 1 commit
  14. 23 Jul, 2018 1 commit
  15. 12 Feb, 2018 1 commit
  16. 19 Dec, 2017 1 commit
  17. 30 Nov, 2017 2 commits
  18. 14 Nov, 2017 1 commit
    • Camillo Bruni's avatar
      [RCS] Add explicit tests for function callbacks · 6526c6dd
      Camillo Bruni authored
      This CL adds a very crude unittest to check that RuntimeCallStats work
      correctly with api callbacks present. This currently doesn't check that
      all parent timers (namely FunctionCallback) are handled properly.
      
      Drive-by-Fix:
      - Use Microseconds for all RCS timer tests
      - Add TestWithContext::SetGlobalProperty helper
      - Use explicit v8:: prefix in test-utils.{h,cc}
      
      Change-Id: I054e78abca0b87a3b9e07d3b06cccdad15403bae
      Reviewed-on: https://chromium-review.googlesource.com/766429
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49348}
      6526c6dd
  19. 10 Nov, 2017 1 commit
  20. 08 Jun, 2017 1 commit
    • kschimpf's avatar
      Localize counter class member functions. · f073a20b
      kschimpf authored
      This CL takes advantage of the fact that StatsCounter is now local to
      the Counters class. This includes:
      
      1) Method StatsTable::SetCreateHistogramFunction() was only called in
      one spot (in api.cc), which also called Counters::ResetHistograms()
      and Counters::InitializeHistorgram(). InitializeHistogram can be
      folded into Histogram.Reset().
      
      2) Since Histogram::Reset() now regenerats the histogram, we no longer
      need the field lookup_done_. Therefore there is no longer a race
      between updating ptr_ and lookup_done_, making the Histogram class
      thread safe.
      
      3) Made the constructors of several classes private (except for class
      Counters), minimizing the scope that they are used. When the couldn't
      be moved, add comment that they were public only for test cases.
      
      4) Removed the need for a mutex lock on StatsCounter::Reset(), since
      it is now guaranteed to only be called when
      StatsTable::SetCounterFunction() is called.
      
      BUG=v8:6361
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2918703002
      Cr-Commit-Position: refs/heads/master@{#45791}
      f073a20b
  21. 24 Nov, 2016 1 commit
    • cbruni's avatar
      [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters · 244dd002
      cbruni authored
      RuntimeTimerScopes always subtract their own time from the parent timer's
      counter to properly account for the own time. Once a scope is destructed it
      adds it own timer to the current active counter. However, if the current
      counter is changed with CorrectCurrentCounterId we will attribute all the
      subtimers to the previous counter, and add the own time to the new counter.
      This way it is possible to end up with negative times in certain counters but
      the overall would still be correct.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2511093002
      Cr-Commit-Position: refs/heads/master@{#41254}
      244dd002
  22. 23 Nov, 2016 2 commits
  23. 21 Nov, 2016 2 commits
    • cbruni's avatar
      Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically... · 10a31136
      cbruni authored
      Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #10 id:180001 of https://codereview.chromium.org/2511093002/ )
      
      Reason for revert:
      Wronged it even more.
      
      Original issue's description:
      > [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
      >
      > RuntimeTimerScopes always subtract their own time from the parent timer's
      > counter to properly account for the own time. Once a scope is destructed it
      > adds it own timer to the current active counter. However, if the current
      > counter is changed with CorrectCurrentCounterId we will attribute all the
      > subtimers to the previous counter, and add the own time to the new counter.
      > This way it is possible to end up with negative times in certain counters but
      > the overall would still be correct.
      >
      > BUG=
      >
      > Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
      > Cr-Commit-Position: refs/heads/master@{#41142}
      
      TBR=ishell@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review-Url: https://codereview.chromium.org/2519073002
      Cr-Commit-Position: refs/heads/master@{#41150}
      10a31136
    • cbruni's avatar
      [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters · f6c74d96
      cbruni authored
      RuntimeTimerScopes always subtract their own time from the parent timer's
      counter to properly account for the own time. Once a scope is destructed it
      adds it own timer to the current active counter. However, if the current
      counter is changed with CorrectCurrentCounterId we will attribute all the
      subtimers to the previous counter, and add the own time to the new counter.
      This way it is possible to end up with negative times in certain counters but
      the overall would still be correct.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2511093002
      Cr-Commit-Position: refs/heads/master@{#41142}
      f6c74d96
  24. 11 May, 2015 1 commit
  25. 07 May, 2015 1 commit
    • ulan's avatar
      Add aggregated memory histograms. · d77839fd
      ulan authored
      This introduces V8.MemoryHeapCommitted and V8.MemoryHeapUsed histograms.
      
      In contrast to the existing memory histograms, the new histograms are uniform in time, i.e. their samples happen at regular time intervals. The --histogram-interval specifies the length of the interval.
      
      We implement this by linearly interpolating memory stats between GC and idle notification events.
      
      BUG=chromium:485472
      LOG=NO
      
      Review URL: https://codereview.chromium.org/1125683004
      
      Cr-Commit-Position: refs/heads/master@{#28292}
      d77839fd