1. 23 Aug, 2013 1 commit
  2. 07 Aug, 2013 1 commit
  3. 03 Jul, 2013 1 commit
  4. 02 Jul, 2013 1 commit
  5. 24 Apr, 2013 1 commit
  6. 19 Apr, 2013 1 commit
  7. 12 Apr, 2013 1 commit
  8. 29 Jan, 2013 1 commit
  9. 28 Nov, 2012 1 commit
  10. 22 Nov, 2012 1 commit
  11. 31 Oct, 2012 1 commit
  12. 16 Jul, 2012 1 commit
  13. 13 Feb, 2012 1 commit
  14. 12 Sep, 2011 2 commits
  15. 24 Jun, 2011 1 commit
  16. 30 Mar, 2011 1 commit
  17. 21 Mar, 2011 1 commit
  18. 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
  19. 10 Feb, 2011 1 commit
  20. 07 Dec, 2010 1 commit
  21. 08 Feb, 2010 2 commits
  22. 04 Feb, 2010 1 commit
  23. 21 Jan, 2010 1 commit
    • mikhail.naganov@gmail.com's avatar
      Fix issue 553: function frame is skipped in profile when compare stub is called. · 999e3fca
      mikhail.naganov@gmail.com authored
      The problem appeared due to a fact that stubs doesn't create a stack
      frame, reusing the stack frame of the caller function. When building
      stack traces, the current function is retrieved from PC, and its
      callees are retrieved by traversing the stack backwards. Thus, for
      stubs, the stub itself was discovered via PC, and then stub's caller's
      caller was retrieved from stack.
      
      To fix this problem, a pointer to JSFunction object is now captured
      from the topmost stack frame, and is saved into stack trace log
      record. Then a simple heuristics is applied whether a referred
      function should be added to decoded stack, or not, to avoid reporting
      the same function twice (from PC and from the pointer.)
      
      BUG=553
      TEST=added to mjsunit/tools/tickprocessor
      
      Review URL: http://codereview.chromium.org/546089
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      999e3fca
  24. 18 Jan, 2010 1 commit
    • mikhail.naganov@gmail.com's avatar
      Fix issue 571: display descriptive names for code objects from snapshot. · 37d39724
      mikhail.naganov@gmail.com authored
      As this is only needed for internal profiling (not for DevTools),
      the following approach had been chosen:
      
       - during snapshot creation, positions of serialized objects inside
         a snapshot are logged;
      
       - then during V8 initialization, positions of deserealized objects
         are logged;
      
       - those positions are used for retrieving code objects names from
         snapshot creation log, which needs to be supplied to tick processor
         script.
      
      Positions logging is controlled with the new flag: --log_snapshot_positions.
      This flag is turned off by default, and this adds no startup penalty.
      
      To plug this fix to Golem, the following actions are needed:
      
       - logs created using 'mksnapshot' need to be stored along with VM images;
      
       - tick processor script needs to be run with '--snapshot-log=...' cmdline
         argument.
      
      BUG=571
      
      Review URL: http://codereview.chromium.org/551062
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3635 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      37d39724
  25. 15 Oct, 2009 1 commit
  26. 02 Sep, 2009 1 commit
  27. 17 Aug, 2009 1 commit
  28. 28 Jul, 2009 1 commit
  29. 14 Jul, 2009 2 commits
  30. 09 Jul, 2009 1 commit
  31. 07 Jul, 2009 2 commits
  32. 20 Jun, 2009 1 commit
  33. 19 Jun, 2009 1 commit
  34. 18 Jun, 2009 1 commit
  35. 17 Jun, 2009 1 commit
  36. 16 Jun, 2009 1 commit
    • mikhail.naganov@gmail.com's avatar
      Fix the problem with JS entries in tickprocessor. · 2cc6fef9
      mikhail.naganov@gmail.com authored
      The main problem was due to the following: after Erik had fixed the logger to report library addresses, tickprocessor started to add to the code map entries that covered almost entire memory. This happened because tickprocessor contains a heuristic to bias addresses of functions from dynamic libraries:
      
          if (funcInfo.start < libStart && funcInfo.start < libEnd - libStart) {
            funcInfo.start += libStart;
          }
      
      And, as tickprocessor tried to process all symbols from the library, including data entries, which can be outside reported library addresses range, the second condition failed, and funcInfo.start remained unbiased.
      
      Review URL: http://codereview.chromium.org/125192
      
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2194 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      2cc6fef9