Skip to content

V
V8
Switch branch/tag
  1. 23 Aug, 2013 1 commit
  3. 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
  5. 07 Jul, 2013 1 commit
    • loislo@chromium.org's avatar
      CPUProfiler: Improve line numbers support in profiler. · 5571dc42
      loislo@chromium.org authored 
      1) report line number even if a script has no resource_name (evals);
  a) do that for already compiled functions in log.cc;
  b) do that for fresh evals in compiler.cc;

2) Implement the test for LineNumbers and make it fast and stable, otherwise we have to wait for tick samples;
  a) move processor_->Join() call into new Processor::StopSynchronously method;
  b) Process all the CodeEvents even if we are stopping Processor thread;
  c) make getters for generator and processor;

3) Fix the test for Jit that didn't expect line numbers;

4) Minor refactoring:
  a) in ProcessTicks;
  b) rename enqueue_order_ to last_code_event_id_ for better readability;
  c) rename dequeue_order_ to last_processed_code_event_id_ and make it a member for better readability;

BUG=
TEST=test-profile-generator/LineNumber
R=jkummerow@chromium.org, yurys@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15530 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      5571dc42
  7. 02 Jul, 2013 2 commits
  9. 01 Jul, 2013 4 commits
  11. 30 Nov, 2012 1 commit
  13. 16 Nov, 2012 1 commit
  15. 17 Oct, 2012 1 commit
  17. 02 Oct, 2012 1 commit
  19. 14 Sep, 2011 1 commit
  21. 13 Jul, 2011 1 commit
  23. 22 Jun, 2011 1 commit
  25. 30 Mar, 2011 1 commit
  27. 10 Mar, 2011 4 commits
  29. 22 Feb, 2011 1 commit
    • mikhail.naganov@gmail.com's avatar
      Fix CPU profiling for Crankshaft. · 56788625
      mikhail.naganov@gmail.com authored 
      The main issue was due to multiple recompilations of functions.  Now
code objects are grouped by function using SFI object address.
JSFunction objects are no longer tracked, instead we track SFI object
moves. To pick a correct code version, we now sample return addresses
instead of JSFunction addresses.

tools/{linux|mac|windows}-tickprocessor scripts differentiate
between code optimization states for the same function
(using * and ~ prefixes introduced earlier).

DevTools CPU profiler treats all variants of function code as
a single function.

ll_prof treats each optimized variant as a separate entry, because
it can disassemble each one of them.

tickprocessor.py not updated -- it is deprecated and will be removed.

BUG=v8/1087,b/3178160
TEST=all existing tests pass, including Chromium layout tests

Review URL: http://codereview.chromium.org/6551011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      56788625
  31. 20 Sep, 2010 1 commit
    • mikhail.naganov@gmail.com's avatar
      Show RegExp calls in the profile. · c1903ce3
      mikhail.naganov@gmail.com authored 
      It turns out they were filtered out. But when I unfiltered them, I
discovered another issue: when DevTools run, regexp literals get
recompiled each time they called (looks like this is concerned with
switching to full compiler), so I ended up having multiple entries for
the same regexp. To fix this, I changed the way of how code entries
equivalence is considered.

BUG=crbug/55999
TEST=cctest/test-profile-generator/ProfileNodeFindOrAddChildForSameFunction
(the test isn't for the whole issue, but rather for equivalence testing)

Review URL: http://codereview.chromium.org/3426008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c1903ce3
  33. 22 May, 2010 1 commit
  35. 18 May, 2010 1 commit
    • mikhail.naganov@gmail.com's avatar
      CPU profiler: add secure profiles by filtering out functions using security tokens. · 3d7ce8ac
      mikhail.naganov@gmail.com authored 
      As several pages can run in a single V8 instance, it is possible to
have functions from different security contexts intermixed in a single
CPU profile.  To avoid exposing function names from one page to
another, filtering is introduced.

The basic idea is that instead of capturing return addresses from
stack, we're now capturing JSFunction addresses (as we anyway work
only with JS stack frames.)  Each JSFunction can reach out for
context's security token. When providing a profile to a page, the
profile is filtered using the security token of caller page. Any
functions with different security tokens are filtered out (yes, we
only do fast path check for now) and their ticks are attributed to
their parents.

Review URL: http://codereview.chromium.org/2083005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      3d7ce8ac
  37. 15 Apr, 2010 1 commit
  39. 14 Apr, 2010 1 commit
  41. 12 Apr, 2010 1 commit
  43. 07 Apr, 2010 1 commit
  45. 06 Apr, 2010 1 commit
  47. 30 Mar, 2010 1 commit
  49. 19 Mar, 2010 1 commit
  51. 11 Mar, 2010 1 commit
  53. 04 Feb, 2010 1 commit
  55. 21 Dec, 2009 1 commit
  57. 27 Aug, 2009 2 commits
  59. 15 Jun, 2009 1 commit
  61. 05 Jun, 2009 1 commit
    • kmillikin@chromium.org's avatar
      Simplify the processing of deferred code in the code generator. Our · bd82b972
      kmillikin@chromium.org authored 
      deferred code snippets are highly stylized.  They always make a call
to a stub or the runtime and then return.  This change takes advantage
of that.

Creating a deferred code object now captures a snapshot of the
registers in the virtual frame.  The registers are automatically saved
on entry to the deferred code and restored on exit.

The clients of deferred code must ensure that there is no change to
the registers in the virtual frame (eg, by allocating which can cause
spilling) or to the stack pointer.  That is currently the case.

As a separate change, I will add either code to verify this constraint
or else code to forbid any frame effect.

The deferred code itself does not use the virtual frame or register
allocator (or even the code generator).  It is raw macro assembler
code.
Review URL: http://codereview.chromium.org/118226

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      bd82b972
  63. 27 May, 2009 1 commit