Skip to content

V
V8
Switch branch/tag
  1. 29 Mar, 2011 1 commit
  3. 28 Mar, 2011 1 commit
  5. 23 Mar, 2011 2 commits
  7. 21 Mar, 2011 1 commit
  9. 18 Mar, 2011 3 commits
  11. 10 Mar, 2011 4 commits
  13. 09 Mar, 2011 1 commit
  15. 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
  17. 04 Jan, 2011 1 commit
  19. 16 Dec, 2010 1 commit
  21. 07 Dec, 2010 4 commits
  23. 25 Nov, 2010 1 commit
  25. 27 Oct, 2010 1 commit
  27. 25 Oct, 2010 3 commits
  29. 20 Oct, 2010 1 commit
  31. 19 Oct, 2010 1 commit
    • vitalyr@chromium.org's avatar
      Support profiling based on linux kernel performance events. · e6b33bd2
      vitalyr@chromium.org authored 
      Since 2.6.31 perf_events interface has been available in the
kernel. There's a nice tool called "perf" (linux-2.6/tools/perf) that
uses this interface and provides capabilities similar to oprofile. The
simplest form of its usage is just dumping the raw log (trace) of
events generated by the kernel. In this patch I'm adding a script
(tools/ll_prof.py) to build profiles based on perf trace and our code
log. All the heavy-lifting is done by perf. Compared to oprofile agent
this approach does not require recompilation and supports code moving
garbage collections.

Expected usage is documented in the ll_prof's help. Basically one
should run V8 under perf passing --ll-prof flag and then the produced
logs can be analyzed by tools/ll_prof.py.

The new --ll-prof flag enables logging of generated code object
locations and names (like --log-code), and also of their bodies, which
can be later disassembled and annotated by the script.

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      e6b33bd2
  33. 18 Oct, 2010 1 commit
  35. 30 Sep, 2010 1 commit
  37. 28 Sep, 2010 2 commits
  39. 24 Sep, 2010 1 commit
  41. 16 Sep, 2010 1 commit
  43. 30 Aug, 2010 1 commit
  45. 25 Jun, 2010 1 commit
  47. 07 Jun, 2010 1 commit
  49. 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
  51. 05 May, 2010 1 commit
  53. 12 Apr, 2010 1 commit
  55. 08 Apr, 2010 1 commit