1. 06 Dec, 2016 1 commit
  2. 02 Dec, 2016 1 commit
  3. 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
  4. 23 Nov, 2016 2 commits
  5. 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
  6. 16 Nov, 2016 1 commit
  7. 15 Nov, 2016 1 commit
  8. 09 Nov, 2016 1 commit
  9. 08 Nov, 2016 1 commit
  10. 04 Nov, 2016 1 commit
  11. 03 Nov, 2016 2 commits
  12. 02 Nov, 2016 1 commit
  13. 28 Oct, 2016 1 commit
    • 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
  14. 19 Oct, 2016 1 commit
  15. 17 Oct, 2016 1 commit
  16. 19 Sep, 2016 1 commit
  17. 16 Sep, 2016 2 commits
    • vogelheim's avatar
      Revert of [Tracing] Remove unnecessary memory allocation in runtime call... · eb7ba290
      vogelheim authored
      Revert of [Tracing] Remove unnecessary memory allocation in runtime call stats. (patchset #1 id:1 of https://codereview.chromium.org/2342643004/ )
      
      Reason for revert:
      Revert because this breaks V8's roll into Chromium. ASAN complains about memory accesses in a particular unit test.
      
      Borked roll CL:
      https://codereview.chromium.org/2348833002/
      
      Reproduce breakage with:
      
      1, args.gn:
        v8_deprecation_warnings = true
        use_goma = true
        is_asan = true
      2, ninja -C out/... content_browsertests
      3, out/.../content_browsertests --gtest_filter=V8SamplingProfilerTest.*
      
      Original issue's description:
      > [Tracing] Remove unnecessary memory allocation in runtime call stats.
      >
      > Previously we didn't implement TRACE_STR_COPY when we write trace events to
      > file, which causes us to allocate a growing independent memory chunk for dumped
      > runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
      > this memory allocation can be avoided, this patch removes it.
      >
      > BUG=v8:5089
      >
      > Committed: https://crrev.com/e1997bb7d780d12e3a89078e8dd652dcf1d90039
      > Cr-Commit-Position: refs/heads/master@{#39462}
      
      TBR=cbruni@chromium.org,fmeawad@chromium.org,lpy@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5089
      
      Review-Url: https://codereview.chromium.org/2349593004
      Cr-Commit-Position: refs/heads/master@{#39475}
      eb7ba290
    • lpy's avatar
      [Tracing] Remove unnecessary memory allocation in runtime call stats. · e1997bb7
      lpy authored
      Previously we didn't implement TRACE_STR_COPY when we write trace events to
      file, which causes us to allocate a growing independent memory chunk for dumped
      runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
      this memory allocation can be avoided, this patch removes it.
      
      BUG=v8:5089
      
      Review-Url: https://codereview.chromium.org/2342643004
      Cr-Commit-Position: refs/heads/master@{#39462}
      e1997bb7
  18. 06 Sep, 2016 1 commit
    • fmeawad's avatar
      [RuntimeCallStats] Fix reset scope for tracing · 5dd94008
      fmeawad authored
      https://codereview.chromium.org/2296243002/ introduced 2 minor bugs
      related to the Reset scope.
      
      The tracing version requires that we reset the counters everytime we
      start a new top level trace event, unless the top level one is not
      really a top level (i.e. has the right type but called in a nested way)
      
      Bugs are:
      1- Reseting was guarded behind a check for the runtime call stats
      version only.
      2- We never set that we are already inside a scope, so the nested
      case would fail as well.
      
      R=lpy@chromium.org, cbruni@chromium.org
      BUG=642373
      
      Review-Url: https://codereview.chromium.org/2311033002
      Cr-Commit-Position: refs/heads/master@{#39214}
      5dd94008
  19. 05 Sep, 2016 1 commit
    • fmeawad's avatar
      [RuntimeCallStats] Move tracing runtime instrumentation closer to the original version. · e5ba156d
      fmeawad authored
      After we landed the tracing runtime call stats, which gave
      us a lot of V8 insight in tracing, we noticed that there is
      some arising issues and discrepancies.
      
      Issues include:
      Missing trace events, that happened due to
      transforming those trace events into runtime calls
      
      Discrepancies include:
      Missing categories in Runtime call stats like GC,
      because we are not handling the Scoped runtime calls
      properly in the tracing version.
      
      To reduce/eliminate those issue, we are taking a small
      step back. We are unifying the RuntimeStats code and
      using the original one. That would allow us to use all
      the original probes but emit trace events from them.
      We are also putting back the trace-events in their place.
      
      The output from both system should be intact (Except of
      the addition of the missing trace-events).
      
      Also as a byproduct, we are reducing the number of context
      scopes by half since we are using the same scope as
      runtime call stats.
      
      As a follow up to this CL, we will address the non-scoped
      Runtime Call Stats (mainly in GC).
      BUG=642373
      
      Review-Url: https://codereview.chromium.org/2296243002
      Cr-Commit-Position: refs/heads/master@{#39180}
      e5ba156d
  20. 10 Aug, 2016 1 commit
  21. 08 Aug, 2016 1 commit
  22. 05 Aug, 2016 1 commit
  23. 03 Aug, 2016 4 commits
  24. 29 Jul, 2016 1 commit
  25. 14 Jul, 2016 1 commit
  26. 30 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] New frame type for exits to C++ builtins · 5febc27b
      jgruber authored
      Prior to this commit, calls to C++ builtins created standard exit
      frames, which are skipped when constructing JS stack traces. In order to
      show these calls on traces, we introduce a new builtin exit frame type.
      
      Builtin exit frames contain target and new.target on the stack and are
      not skipped during stack trace construction.
      
      BUG=v8:4815
      R=bmeurer@chromium.org, yangguo@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
      
      Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
      Review-Url: https://codereview.chromium.org/2090723005
      Cr-Original-Commit-Position: refs/heads/master@{#37384}
      Cr-Commit-Position: refs/heads/master@{#37416}
      5febc27b
  27. 29 Jun, 2016 2 commits
  28. 17 Jun, 2016 1 commit
  29. 13 Jun, 2016 1 commit
    • jkummerow's avatar
      [--runtime-call-stats] Fix ACCESSOR handler computation · 31ca317a
      jkummerow authored
      When running with FLAG_runtime_call_stats, native accessor accesses must
      go through the runtime for accurate accounting. Previously the slow_stub()
      was used as a handler in order to accomplish this, but it could never be
      looked up from the code cache successfully due to mismatched code flags,
      which could cause more handler recompilations than in normal operation.
      This patch fixes that by emitting a runtime call into the compiled
      handler instead of using the slow_stub().
      
      Drive-by cleanup: drop the unused StoreIC_Megamorphic builtin.
      
      Review-Url: https://codereview.chromium.org/2054133002
      Cr-Commit-Position: refs/heads/master@{#36926}
      31ca317a
  30. 10 Jun, 2016 1 commit
  31. 30 May, 2016 1 commit
  32. 13 May, 2016 1 commit
    • cbruni's avatar
      [counters] Annotate v8 with more runtime call counters. · 407d9fce
      cbruni authored
      By fully annotating the API with runtime counters we can properly measure
      how much time we spend in total in v8. When --runtime-call-stats is specified
      we now disable the fast-paths for callbacks to properly measure them.
      As a drive-by-fix this CL unifies the LOG messages in api.cc.
      Additionally we added missing timers to gain better resolution in the parser
      and callbacks.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/1923893002
      Cr-Commit-Position: refs/heads/master@{#36248}
      407d9fce