Skip to content

V
V8
Switch branch/tag
  1. 20 Aug, 2015 1 commit
  3. 12 Aug, 2015 1 commit
    • mstarzinger's avatar
      Remove inline header includes from non-inline headers (1). · 00a07bc1
      mstarzinger authored 
      This tries to remove includes of "-inl.h" headers from normal ".h"
headers, thereby reducing the chance of any cyclic dependencies and
decreasing the average size of our compilation units.

Note that this change still leaves 7 violations of that rule in the
code. However there now is the "tools/check-inline-includes.sh" tool
detecting such violations.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1283033003

Cr-Commit-Position: refs/heads/master@{#30125}
      00a07bc1
  5. 01 Jun, 2015 1 commit
  7. 04 May, 2015 1 commit
  9. 01 Apr, 2015 1 commit
  11. 24 Mar, 2015 1 commit
  13. 17 Mar, 2015 1 commit
  15. 09 Mar, 2015 1 commit
    • loislo's avatar
      CpuProfiler: fix for GetDeoptReason code. · 66ab309e
      loislo authored 
      The original code always returned the first entry from RelocInfo that matched with
bailout_id. But we may have a few different deopt reasons for one bailout_id.
So we need to get the one which matches with a particular call from JumpTable.

We can do this by checking not 'target_address' (it maps to bailout_id)
but 'from' address which maps to a particular JumpTable entry.

The test was reworked so it tests identical functions against different reasons.

BUG=chromium:452067
LOG=n

Review URL: https://codereview.chromium.org/984773003

Cr-Commit-Position: refs/heads/master@{#27076}
      66ab309e
  17. 27 Feb, 2015 1 commit
  19. 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
  21. 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
  23. 13 Nov, 2014 1 commit
  25. 12 Nov, 2014 1 commit
  27. 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
  29. 17 Oct, 2014 1 commit
  31. 07 Oct, 2014 1 commit
  33. 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
  35. 05 Aug, 2014 1 commit
  37. 04 Aug, 2014 1 commit
  39. 30 Jun, 2014 1 commit
  41. 03 Jun, 2014 1 commit
  43. 22 May, 2014 1 commit
  45. 06 May, 2014 1 commit
  47. 29 Apr, 2014 1 commit
  49. 25 Apr, 2014 1 commit
  51. 10 Jan, 2014 1 commit
  53. 18 Dec, 2013 1 commit
  55. 11 Dec, 2013 1 commit
  57. 10 Oct, 2013 2 commits
  59. 17 Sep, 2013 1 commit
    • dslomov@chromium.org's avatar
      Make v8 compile on VS2013. · 9f5edd1b
      dslomov@chromium.org authored 
      VS2013 contains a number of improvements, most notably the addition of all C99 math functions.

I'm a little bit concerned about the change I had to make in cpu-profiler.cc, but I spent quite a bit of time looking at it and was unable to figure out any rational explanation for the warning.  It's possible it's spurious.  Since it seems like a useful warning in general though, I chose not to disable globally at the gyp level.

I do think someone with expertise here should probably try to determine if this is a legitimate warning.

BUG=288948
R=dslomov@chromium.org

Review URL: https://codereview.chromium.org/23449035

Patch from Zach Turner <zturner@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16775 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      9f5edd1b
  61. 11 Sep, 2013 1 commit
  63. 06 Sep, 2013 1 commit
    • yurys@chromium.org's avatar
      Check if timeout has expired after processing each sample · 43780dbd
      yurys@chromium.org authored 
      To avoid long intervals between taking samples due to processing all accumulated samples at once, the samples are processed one by one and we check if the sampling interval has elapsed after each step rather than after processing all the samples in the queue.

This is a modified version of r16549 whith a fix for test flakiness. The test flakiness introduced by the previous version of this changed was fixed by changing return type of ProfilerEventsProcessor::ProcessOneSample from bool to enum with 3 options. In the main profiling loop we decide that the next code event should be processed when sample with a greater ordinal number is encountered. When processing remaining samples we shouldn't wait for more samples and if the samples queue is empty we just process next code event.

BUG=v8:2814,v8:2871
R=bmeurer@chromium.org, loislo@chromium.org

Review URL: https://codereview.chromium.org/23455036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16564 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      43780dbd
  65. 05 Sep, 2013 5 commits
  67. 04 Sep, 2013 1 commit