Skip to content

V
V8
Switch branch/tag
  1. 30 Jan, 2015 2 commits
  3. 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
  5. 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
  7. 22 May, 2014 1 commit
  9. 09 May, 2014 1 commit
  11. 29 Apr, 2014 1 commit
  13. 25 Apr, 2014 1 commit
  15. 19 Apr, 2014 1 commit
  17. 28 Mar, 2014 1 commit
  19. 17 Mar, 2014 2 commits
  21. 14 Mar, 2014 1 commit
  23. 18 Feb, 2014 1 commit
  25. 23 Dec, 2013 1 commit
  27. 18 Dec, 2013 3 commits
  29. 11 Dec, 2013 1 commit
  31. 02 Dec, 2013 1 commit
  33. 14 Oct, 2013 1 commit
  35. 10 Oct, 2013 1 commit
  37. 30 Sep, 2013 1 commit
  39. 10 Sep, 2013 1 commit
  41. 05 Sep, 2013 1 commit
  43. 04 Sep, 2013 1 commit
  45. 27 Aug, 2013 1 commit
  47. 26 Aug, 2013 1 commit
  49. 09 Aug, 2013 1 commit
  51. 08 Aug, 2013 2 commits
  53. 07 Aug, 2013 1 commit
  55. 06 Aug, 2013 2 commits
  57. 05 Aug, 2013 3 commits
  59. 06 Jul, 2013 1 commit
  61. 04 Jul, 2013 1 commit