1. 19 Feb, 2019 1 commit
  2. 06 Apr, 2016 1 commit
  3. 05 Apr, 2016 1 commit
  4. 26 Feb, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add support for cpu profiler logging. · cb29f9cd
      rmcilroy authored
      Adds support for cpu profiler logging to the interpreter. Modifies the
      the API to be passed AbstractCode objects instead of Code objects, and
      adds extra functions to AbstractCode which is required by log.cc and
      cpu-profiler.cc.
      
      The main change in sampler.cc is to determine if a stack frame is an
      interpreter stack frame, and if so, use the bytecode address as the pc
      for that frame. This allows sampling of bytecode functions. This
      requires adding support to SafeStackIterator to determine if a frame is
      interpreted, which we do by checking the PC against pre-stored addresses
      for the start and end of interpreter entry builtins.
      
      Also removes CodeDeleteEvents which are dead code and haven't
      been reported for some time.
      
      Still to do is tracking source positions which will be done in a
      followup CL.
      
      BUG=v8:4766
      LOG=N
      
      Review URL: https://codereview.chromium.org/1728593002
      
      Cr-Commit-Position: refs/heads/master@{#34321}
      cb29f9cd
  5. 22 Jan, 2016 2 commits
    • mtrofin's avatar
      ll_prof: add decimal offset · 379bbd50
      mtrofin authored
      This simplifies correlating offsets with the output from
      --print-opt-code, which outputs offsets in decimal.
      
      We keep the hex output since branch instructions in the perf dump use
      hex labels. We just include the decimal offset along with the hex offset.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1612403002
      
      Cr-Commit-Position: refs/heads/master@{#33455}
      379bbd50
    • mtrofin's avatar
      [ll_prof] show tick count · 018a1f88
      mtrofin authored
      Show tick count, besides the percentage spent on an
      instruction. Aids perf investigations where we deal with
      stalls, for example. Percentage-wise, the execution appears
      distributed similarly, but the regression becomes more
      apparent in the tick counts.
      
      Review URL: https://codereview.chromium.org/1607323003
      
      Cr-Commit-Position: refs/heads/master@{#33452}
      018a1f88
  6. 26 Nov, 2015 1 commit
  7. 16 Mar, 2015 1 commit
  8. 24 Jun, 2014 1 commit
  9. 07 Dec, 2012 1 commit
  10. 06 Sep, 2012 1 commit
  11. 13 Jan, 2012 1 commit
  12. 09 Nov, 2011 1 commit
  13. 19 Sep, 2011 1 commit
  14. 29 Jun, 2011 1 commit
  15. 18 May, 2011 1 commit
  16. 29 Apr, 2011 1 commit
  17. 22 Feb, 2011 2 commits
    • 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
    • vitalyr@chromium.org's avatar
      grokdump: Simple windows minidump analysis on linux. · 25f2f21f
      vitalyr@chromium.org authored
      Analyses full minidump (.dmp) files.
      
      Shows the processor state at the point of exception including the
      stack of the active thread and the referenced objects in the V8
      heap. Code objects are disassembled and the addresses linked from the
      stack (pushed return addresses) are marked with "=>".
      
      Review URL: http://codereview.chromium.org/6312058
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6896 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      25f2f21f
  18. 07 Dec, 2010 2 commits
  19. 28 Oct, 2010 1 commit
  20. 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