1. 27 Feb, 2015 1 commit
  2. 20 Feb, 2015 2 commits
    • loislo's avatar
      CpuProfiler: move StringsStorage class to separate source and header files. · 9b02dc5b
      loislo authored
      Mechanical change.
      
      This will break dependency between profiler-generator and heap-profiler-generator.
      Later this will help us to reuse SourcePosition in cpu-profiler.
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/945873002
      
      Cr-Commit-Position: refs/heads/master@{#26780}
      9b02dc5b
    • 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
  3. 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
  4. 11 Feb, 2015 1 commit
  5. 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
  6. 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
  7. 05 Nov, 2014 1 commit
  8. 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
  9. 05 Aug, 2014 1 commit
  10. 30 Jun, 2014 1 commit
  11. 20 Jun, 2014 1 commit
  12. 03 Jun, 2014 1 commit
  13. 29 Apr, 2014 1 commit
  14. 25 Apr, 2014 1 commit
  15. 19 Apr, 2014 1 commit
  16. 18 Dec, 2013 1 commit
  17. 18 Oct, 2013 1 commit
  18. 14 Oct, 2013 1 commit
  19. 10 Oct, 2013 1 commit
  20. 11 Sep, 2013 1 commit
  21. 05 Sep, 2013 1 commit
  22. 02 Sep, 2013 1 commit
  23. 29 Aug, 2013 1 commit
  24. 28 Aug, 2013 6 commits
  25. 27 Aug, 2013 1 commit
  26. 07 Aug, 2013 1 commit
  27. 06 Aug, 2013 1 commit
  28. 05 Aug, 2013 3 commits
  29. 30 Jul, 2013 1 commit
    • yurys@chromium.org's avatar
      Simplify sampling rate calculation · 6ba502fa
      yurys@chromium.org authored
      Sampling rate is now calculated as total number of samples divided by profiling time in ms. Before the patch the sampling rate was updated once per 100ms which doesn't have any obvious advantage over the simpler method.
      
      Also we are going to get rid of the profile node self and total time calculation in the v8 CPU profiler and only expose profiling start/end time for CpuProfile and number of ticks on each ProfileNode and let clients do all the math should they need it.
      
      BUG=None
      R=bmeurer@chromium.org, loislo@chromium.org
      
      Review URL: https://codereview.chromium.org/21105003
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      6ba502fa