1. 03 Apr, 2019 1 commit
  2. 13 Mar, 2019 1 commit
  3. 23 May, 2018 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Add a new profiling mode with a more detailed call tree. · ecae80cd
      Peter Marshall authored
      The current profiling mode (called kLeafNodeLineNumbers in this CL)
      produces a tree, with each node representing a stack frame that is seen
      in one or more samples taken during profiling. These nodes refer to a
      particular function in a stack trace, but not to a particular line or
      callsite within that function.
      
      This CL adds a new more (called kCallerLineNumbers) which produces a
      different profile tree, where each stack trace seen during profiling,
      including the line number, has a unique path in the tree.
      
      The profile tree was previously keyed on CodeEntry*. Now it is keyed on
      the pair of CodeEntry* and line_number, meaning it has distinct nodes
      for those combinations which exist, and each distinct stack trace that
      was sampled is represented in the tree.
      
      For optimized code where we have inline frames, there are no line
      numbers for the inline frames in the stack trace, causing duplicate
      branches in the tree with kNoLineNumberInfo as the reported line number.
      This will be addressed in follow-ups.
      
      Bug: v8:7018
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I512e221508f5b50ec028306d212263b514a9fb24
      Reviewed-on: https://chromium-review.googlesource.com/1013493
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53298}
      ecae80cd
  4. 18 May, 2018 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Move bailout reason into rare_info struct · 29ea4d1e
      Peter Marshall authored
      This was set very regularly in FillFunctionInfo, but it was almost
      always set to kNoReason, because the associated SFI had no bailout
      reason. Given that having a bailout reason is the rare case, we
      just assume an empty bailout reason, and use the rare_data_ struct
      to store the string pointer if we do need it.
      
      This saves another pointer of space on the CodeEntry object (approx
      1.4 MiB on the node server example).
      
      Bug: v8:7719
      Change-Id: I8e2272b572285ddf353ba0b303e6da095b7d5272
      Reviewed-on: https://chromium-review.googlesource.com/1064370
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53244}
      29ea4d1e
  5. 16 May, 2018 1 commit
    • Alexei Filippov's avatar
      [cpu-profiler] Eagerly delete not used CodeEntry'es · c6c28f7a
      Alexei Filippov authored
      Currently ProfilerListener holds all the CodeEntries it ever
      created during the profiling session. It is not capable of removing
      entries corresponding to the code objects discarded by GC as there's
      no such code event.
      
      However it is sometimes possible to tell if a code object was GCed.
      Hook up to the CodeMap code entry removal and if the entry has never
      been hit by a sample we can safely delete it.
      
      As a bonus the CodeEntryInfo size has been reduced on x64, which also
      saves 8 x <number of code entries> bytes.
      
      BUG=v8:7719
      
      Change-Id: I988bc5b59f3fba07157a9f472cbcf68596fcd969
      Reviewed-on: https://chromium-review.googlesource.com/1054346Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Alexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53222}
      c6c28f7a
  6. 07 May, 2018 2 commits
  7. 23 Apr, 2018 1 commit
  8. 12 Apr, 2018 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Fix bugs and add tests for JITLineInfoTable · 4feb5ce7
      Peter Marshall authored
      Looking up line numbers with the JITLineInfoTable would sometimes give
      wrong answers. Fix these bugs and add a cctest for this data structure.
      
      Also do some cleanup while we're here like inlining the (empty)
      constructor and destructor and removing the empty() method which is
      only used unnecessarily anyway, to make the contract of
      GetSourceLineNumber a bit clearer.
      
      Also rename the data structure to SourcePositionTable, because it
      doesn't just provide info for JIT code, but also bytecode, and 'Info'
      is pretty ambiguous.
      
      Bug: v8:7018
      Change-Id: I126581c844d85df6b2b3f80f2f5acbce01c16ba1
      Reviewed-on: https://chromium-review.googlesource.com/1006795Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52571}
      4feb5ce7
  9. 05 Feb, 2018 1 commit
  10. 20 Dec, 2016 1 commit
  11. 07 Dec, 2016 1 commit
  12. 22 Nov, 2016 1 commit
    • tebbi's avatar
      [cpu-profiler] use new source position information for deoptimization in cpu profiler · 1b320d20
      tebbi authored
      The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results.
      
      Other changes in this CL:
      - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front.
      - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan.
      - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention.
      - I removed CodeDeoptEvent::position, as it is no longer used.
      
      R=alph@chromium.org
      
      BUG=v8:5432
      
      Review-Url: https://codereview.chromium.org/2503393002
      Cr-Commit-Position: refs/heads/master@{#41168}
      1b320d20
  13. 06 Oct, 2016 1 commit
    • alph's avatar
      [profiler] Tracing-based CPU profiler. · 4b575dfc
      alph authored
      A new V8 API object v8::TracingCpuProfiler is introduced.
      Client can create it on an isolate to enable JS CPU profiles collected
      during tracing session.
      
      Once the v8.cpu_profile2 tracing category is enabled the profiler emits
      CpuProfile and CpuProfileChunk events with the profile data.
      
      BUG=chromium:406277
      
      Review-Url: https://codereview.chromium.org/2396733002
      Cr-Commit-Position: refs/heads/master@{#40054}
      4b575dfc
  14. 19 Jul, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Allow deopt reasons without source positions. · ca727047
      mstarzinger authored
      This allows to pass deoptimization reasons to the profiler without the
      requirement of always providing a source position. The absence of deopt
      reasons is now communicated via a sentinel as the deopt id value. The
      deoptimization reasons recently added to TurboFan are now passed to the
      profiler.
      
      R=bmeurer@chromium.org
      TEST=cctest/test-cpu-profiler
      
      Review-Url: https://codereview.chromium.org/2159793002
      Cr-Commit-Position: refs/heads/master@{#37852}
      ca727047
  15. 15 Jun, 2016 1 commit
  16. 30 Nov, 2015 1 commit
  17. 01 Oct, 2015 1 commit
    • alph's avatar
      Eliminate no_frame_range data · 8d55da38
      alph authored
      It was supposed to be used by the CPU profiler. But as long as
      these ranges are not built when profiler is not running, once
      the profiler is started there're no ranges for already compiled
      functions. So basically this code never worked.
      
      As long as now CPU profiler uses another approach this code is no
      longer needed.
      
      Review URL: https://codereview.chromium.org/1376333003
      
      Cr-Commit-Position: refs/heads/master@{#31056}
      8d55da38
  18. 30 Sep, 2015 1 commit
  19. 28 Sep, 2015 1 commit
  20. 11 Sep, 2015 1 commit
  21. 27 Feb, 2015 1 commit
  22. 20 Feb, 2015 1 commit
    • loislo's avatar
      CpuProfiler: eliminate cpu-profiler dependency from heap-inl.h · 8ba89cce
      loislo authored
      We accessed to cpu_profiler for tracking SharedFunctionInfo objects movements and used their addresses for generating function_id. Actually we could replace the manually generated shared_id by the pair script_id + position. In this case we can drop SharedFunctionInfo events support from cpu_profiler and remove the dependency.
      
      BTW GetCallUid was used as an unique identifier of the function on the front-end side. Actually it is a hash which might not be unique. So I renamed GetCallUid with GetHash and implemented GetFunctionId method.
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/941973002
      
      Cr-Commit-Position: refs/heads/master@{#26775}
      8ba89cce
  23. 12 Feb, 2015 3 commits
    • loislo's avatar
      CPUProfiler: Push deopt reason further to ProfileNode. · d23ab23b
      loislo authored
      1) create beefy RelocInfo table when cpu profiler is active, so if a function
      was optimized when profiler was active RelocInfo would get separate DeoptInfo
      for the each deopt case.
      
      2) push DeoptInfo from CodeEntry to ProfileNode.
      When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
      On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
      
      Sample profile dump.
      [Top down]:
          0  (root) 0 #1
          1     29 #2
          1      test 29 #3
          2        opt_function 29 #4
          2          opt_function 29 #5
                         deopted at 118 with reason 'not a heap number'
                         deopted at 137 with reason 'division by zero'
      
      BUG=452067
      LOG=n
      
      Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54
      Cr-Commit-Position: refs/heads/master@{#26615}
      
      Review URL: https://codereview.chromium.org/919953002
      
      Cr-Commit-Position: refs/heads/master@{#26630}
      d23ab23b
    • loislo's avatar
      Revert of CPUProfiler: Push deopt reason further to ProfileNode. (patchset #1... · cb6ea146
      loislo authored
      Revert of CPUProfiler: Push deopt reason further to ProfileNode. (patchset #1 id:1 of https://codereview.chromium.org/919953002/)
      
      Reason for revert:
      static initializers broke the build
      
      Original issue's description:
      > CPUProfiler: Push deopt reason further to ProfileNode.
      >
      > 1) create beefy RelocInfo table when cpu profiler is active, so if a function
      > was optimized when profiler was active RelocInfo would get separate DeoptInfo
      > for the each deopt case.
      >
      > 2) push DeoptInfo from CodeEntry to ProfileNode.
      > When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
      > On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
      >
      > Sample profile dump.
      > [Top down]:
      >     0  (root) 0 #1
      >     1     29 #2
      >     5      test 29 #3
      >     3        opt_function 29 #4
      >                  deopted at 52 with reason 'not a heap number'
      >                  deopted at 71 with reason 'division by zero'
      >
      > BUG=452067
      > LOG=n
      >
      > Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54
      > Cr-Commit-Position: refs/heads/master@{#26615}
      
      TBR=jarin@chromium.org,svenpanne@chromium.org,yurys@chromium.org,alph@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=452067
      
      Review URL: https://codereview.chromium.org/915173005
      
      Cr-Commit-Position: refs/heads/master@{#26616}
      cb6ea146
    • loislo's avatar
      CPUProfiler: Push deopt reason further to ProfileNode. · ce8701b2
      loislo authored
      1) create beefy RelocInfo table when cpu profiler is active, so if a function
      was optimized when profiler was active RelocInfo would get separate DeoptInfo
      for the each deopt case.
      
      2) push DeoptInfo from CodeEntry to ProfileNode.
      When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
      On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
      
      Sample profile dump.
      [Top down]:
          0  (root) 0 #1
          1     29 #2
          5      test 29 #3
          3        opt_function 29 #4
                       deopted at 52 with reason 'not a heap number'
                       deopted at 71 with reason 'division by zero'
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/919953002
      
      Cr-Commit-Position: refs/heads/master@{#26615}
      ce8701b2
  24. 10 Feb, 2015 1 commit
    • loislo's avatar
      Propagate DeoptInfo to cpu-profiler · 86cae163
      loislo authored
      1) Deoptimizer::Reason was replaced with Deoptimizer::DeoptInfo
      because it also has raw position. Also the old name clashes with DeoptReason enum.
      
      2) c_entry_fp assignment call was added to EntryGenerator::Generate
      So we can calculate sp and have a chance to record the stack for the deopting function.
      btw it makes the test stable.
      
      3) new kind of CodeEvents was added to cpu-profiler
      
      4) GetDeoptInfo method was extracted from PrintDeoptLocation.
      So it could be reused in cpu profiler.
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/910773002
      
      Cr-Commit-Position: refs/heads/master@{#26545}
      86cae163
  25. 06 Nov, 2014 1 commit
    • svenpanne@chromium.org's avatar
      The idea behind of this solution is to use the existing "relocation info"... · d56a21eb
      svenpanne@chromium.org authored
      The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
      During generation code and relocation info are generated simultaneously.
      When code generation is done you each code object has associated "relocation info".
      Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
      correspondences between the machine program counter and source locations for stack walking.
      
      This patch:
      1. Add more source positions info in reloc info to make it suitable for source level mapping.
      The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
      (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
      I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
      
      2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
      If a source line is found that hit counter is increased by one for this line.
      
      3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
      Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
      
      4.Add a test that checks how the samples are distributed through source lines.
      It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
      
      Patch from Denis Pravdin <denis.pravdin@intel.com>;
      
      R=svenpanne@chromium.org, yurys@chromium.org
      
      Review URL: https://codereview.chromium.org/682143003
      
      Patch from Weiliang <weiliang.lin@intel.com>.
      
      Cr-Commit-Position: refs/heads/master@{#25182}
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d56a21eb
  26. 05 Nov, 2014 1 commit
  27. 02 Oct, 2014 2 commits
    • yurys@chromium.org's avatar
      Revert of Extend CPU profiler with mapping ticks to source lines (patchset #3... · 08c40baa
      yurys@chromium.org authored
      Revert of Extend CPU profiler with mapping ticks to source lines (patchset #3 id:40001 of https://codereview.chromium.org/616963005/)
      
      Reason for revert:
      It broke layout test fast/events/window-onerror-02.html, error column reported by window.onerror is now wrong (I believe it is because of the change in full-codegen):
      
      http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/652
      
      Original issue's description:
      > Extend CPU profiler with mapping ticks to source lines
      >
      > The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
      > During generation code and relocation info are generated simultaneously.
      > When code generation is done you each code object has associated "relocation info".
      > Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
      > correspondences between the machine program counter and source locations for stack walking.
      >
      > This patch:
      > 1. Add more source positions info in reloc info to make it suitable for source level mapping.
      > The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
      > (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
      > I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
      >
      > 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
      > If a source line is found that hit counter is increased by one for this line.
      >
      > 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
      > Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
      >
      > 4.Add a test that checks how the samples are distributed through source lines.
      > It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
      >
      > Patch from Denis Pravdin <denis.pravdin@intel.com>
      > BUG=None
      > LOG=Y
      > R=svenpanne@chromium.org
      >
      > Committed: https://code.google.com/p/v8/source/detail?r=24389
      
      TBR=svenpanne@chromium.org,danno@chromium.org,alph@chromium.org,denis.pravdin@intel.com,weiliang.lin@intel.com
      BUG=None
      LOG=N
      
      Review URL: https://codereview.chromium.org/624443005
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      08c40baa
    • yurys@chromium.org's avatar
      Extend CPU profiler with mapping ticks to source lines · 6482fb3e
      yurys@chromium.org authored
      The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
      During generation code and relocation info are generated simultaneously.
      When code generation is done you each code object has associated "relocation info".
      Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
      correspondences between the machine program counter and source locations for stack walking.
      
      This patch:
      1. Add more source positions info in reloc info to make it suitable for source level mapping.
      The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
      (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
      I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
      
      2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
      If a source line is found that hit counter is increased by one for this line.
      
      3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
      Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
      
      4.Add a test that checks how the samples are distributed through source lines.
      It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
      
      Patch from Denis Pravdin <denis.pravdin@intel.com>
      BUG=None
      LOG=Y
      R=svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/616963005
      
      Patch from Denis Pravdin <denis.pravdin@intel.com>.
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      6482fb3e
  28. 03 Jun, 2014 1 commit
  29. 29 Apr, 2014 1 commit
  30. 14 Mar, 2014 1 commit
  31. 13 Mar, 2014 2 commits
  32. 18 Oct, 2013 1 commit
  33. 14 Oct, 2013 1 commit
  34. 10 Oct, 2013 1 commit
  35. 05 Sep, 2013 1 commit