Skip to content

V
V8
Switch branch/tag
  1. 08 Dec, 2016 1 commit
  3. 05 Dec, 2016 1 commit
  5. 02 Dec, 2016 2 commits
  7. 29 Nov, 2016 1 commit
  9. 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
  11. 23 Nov, 2016 3 commits
  13. 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
  15. 16 Nov, 2016 1 commit
  17. 15 Nov, 2016 1 commit
  19. 13 Nov, 2016 1 commit
  21. 10 Nov, 2016 1 commit
  23. 08 Nov, 2016 1 commit
  25. 07 Nov, 2016 1 commit
  27. 04 Nov, 2016 1 commit
  29. 03 Nov, 2016 3 commits
  31. 02 Nov, 2016 1 commit
  33. 31 Oct, 2016 1 commit
  35. 28 Oct, 2016 2 commits
    • alph's avatar
      [profiler] Emit runtime call stats into sampling profile · aee3542f
      alph authored 
      These are added to the sampler stack trace when RCS are
enabled.
Resource name for a RCS frame is reported as "V8Runtime".
Counter names match ones from src/counters.h

BUG=chromium:660428

Review-Url: https://codereview.chromium.org/2461003002
Cr-Commit-Position: refs/heads/master@{#40658}
      aee3542f
    • lpy's avatar
      [Tracing] Fix inaccurate timer calculation in runtime statistics. · 92d9a56a
      lpy authored 
      Previously we reset runtime counters and dump them when we enter, exit top level
trace events respectively. However, there is gap between two top level trace
events and runtime counters may be activated, resetting the counters makes the
accumulated time inaccurate, and we may end up with negative time due to the
nature of how we accumulate time.

This patch fixes this problem by only resetting counters when there's no
counters active, and before dump counters, we traverse current active counters
to calculate their time, and then restart their timer.

BUG=chromium:658145

Review-Url: https://codereview.chromium.org/2457523002
Cr-Commit-Position: refs/heads/master@{#40653}
      92d9a56a
  37. 25 Oct, 2016 1 commit
  39. 24 Oct, 2016 2 commits
  41. 21 Oct, 2016 4 commits
  43. 19 Oct, 2016 1 commit
  45. 17 Oct, 2016 1 commit
  47. 14 Oct, 2016 5 commits
  49. 13 Oct, 2016 1 commit