1. 31 May, 2021 1 commit
  2. 21 Apr, 2021 1 commit
  3. 09 Dec, 2020 1 commit
  4. 30 Nov, 2020 1 commit
  5. 10 Nov, 2020 1 commit
  6. 04 Nov, 2020 1 commit
  7. 28 Sep, 2020 1 commit
  8. 06 Feb, 2020 1 commit
    • Tobias Tebbi's avatar
      [profiler] fix 4 bugs in --prof/linux-tick-processor · 58b45cca
      Tobias Tebbi authored
      - In log.cc, we used InstructionStart() for code create events, but
        the Code object address for code move events. Change to use
        InstructionStart() for both.
      - The symbol table contains some kind of virtual address, not file
        offsets. They happened to be identical in the past but are no longer,
        probably due to toolchain changes. Now we use objdump to figure out
        the difference between virtual addresses and file offsets.
      - When a new code object happened to be created at the same address as
        a previous one, we wouldn't update it.
        This is indeed wrong, as predicted in a TODO by Jaro.
      - For 64bit addresses, using >>> is wrong, now replaced with division.
      
      
      Change-Id: Ib23114ed736f98bfc33c65004a039a3fd04d3c49
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016586Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66145}
      58b45cca
  9. 27 May, 2019 1 commit
  10. 22 Jun, 2018 1 commit
  11. 23 Apr, 2018 1 commit
    • jgruber's avatar
      [prof] Attribute ticks in embedded builtins correctly · 384a51da
      jgruber authored
      When attributing ticks to a function, we first check if the current pc
      matches a section within the dynamic library. If we find a match here,
      then we don't continue looking within dynamically generated range
      information, e.g. for JS functions and builtins.
      
      This logic breaks when embedded builtins come into play. They live
      within the libv8.so shared library, and are found when looking up
      statics. But what we really want is to look up the dynamically
      generated code-range, which contains more precise information.
      
      In this CL, this case is detected by matching the found symbol name.
      If it's the embedded blob, then we continue to dynamic lookup.
      
      Bug: v8:6666
      Change-Id: I7cea2cd4898f5a08381a071bdbc2f862b9c80880
      Reviewed-on: https://chromium-review.googlesource.com/1023422
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52723}
      384a51da
  12. 04 Mar, 2017 1 commit
  13. 28 Apr, 2016 1 commit
    • lpy's avatar
      Dump C++ symbols and merge into v8 log. · aff44193
      lpy authored
      Currently we already have tools to extract C++ symbols of d8, and output the
      statistics result. This patch creates two scripts, one is to use exsisting tools
      to extract C++ symbols and dump to output, the other collects all symbols and
      merges them into v8 log. The format of C++ symbols in v8 log is:
      
      cpp,start_address,size,symbol_name
      
      BUG=v8:4906
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1884493003
      Cr-Commit-Position: refs/heads/master@{#35841}
      aff44193
  14. 17 Oct, 2014 1 commit
  15. 14 Sep, 2011 1 commit
  16. 12 Sep, 2011 2 commits
  17. 13 Jul, 2011 1 commit
  18. 10 Feb, 2011 1 commit
  19. 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
  20. 25 Nov, 2009 1 commit
  21. 14 Jul, 2009 1 commit
  22. 16 Jun, 2009 1 commit
  23. 08 May, 2009 1 commit
  24. 27 Apr, 2009 1 commit
    • mikhail.naganov@gmail.com's avatar
      TickProcessor script reimplemented in JavaScript. · aa2c3312
      mikhail.naganov@gmail.com authored
      This is an effort to reuse profiler data processing code both in
      TickProcessor and Dev Tools Profiler. The old Python implementation
      will be removed.
      
      The new TickProcessor works almost identical to the previous one.
      However, it has some differences:
      
      1. Not very useful "Call profile" section is replaced with a new
         WebKit-like "Bottom up (heavy) profile" which shows the most
         expensive functions together with their callers. I used it
         personally in order to find and remove bottlenecks in the
         tickprocessor script itself, and found it quite helpful.
      
      2. Code entries with duplicate names (they occur for RegExes, stubs
         and sometimes for anonymous Function objects) are now distinguished
         by adding an occurence number inside curly brackets.
      
      3. (Address -> code entry) mapping is more precise in boundary cases.
      
      4. Windows version no more requires specifying .map file location.
      
      5. Works faster.
      
      Review URL: http://codereview.chromium.org/99054
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      aa2c3312
  25. 17 Apr, 2009 1 commit
  26. 16 Apr, 2009 1 commit