Skip to content

V
V8
Switch branch/tag
  1. 09 Jul, 2009 1 commit
  3. 08 Jul, 2009 4 commits
  5. 07 Jul, 2009 3 commits
  7. 24 Jun, 2009 1 commit
  9. 20 Jun, 2009 1 commit
  11. 19 Jun, 2009 1 commit
  13. 18 Jun, 2009 1 commit
  15. 17 Jun, 2009 2 commits
  17. 16 Jun, 2009 4 commits
    • 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
    • erik.corry@gmail.com's avatar
      Use >>> instead of >> in order to cover the full 32 bit range when · 398c5a9b
      erik.corry@gmail.com authored 
      handling addresses.
Review URL: http://codereview.chromium.org/125187

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2193 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      398c5a9b
    • erik.corry@gmail.com's avatar
      Don't panic if tickprocessor can't find a shared library. · 92bbf759
      erik.corry@gmail.com authored 
      Don't swallow exceptions so we can't see where they are really
thrown.
Review URL: http://codereview.chromium.org/126200

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2192 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      92bbf759
    • sgjesse@chromium.org's avatar
      Added utility scripts for running oprofile in tools/oprofile. · 78a8cdfb
      sgjesse@chromium.org authored 
      To profile running the JavaScript file test.js using the V8 release mode shell (assuming it is build passing prof=oprofile to the SCons build). The following commands can be used:

$ tools/oprofile/start
$ tools/oprofile/run test.js
$ tools/oprofile/report | less
$ tools/oprofile/annotate | less
$ tools/oprofile/shutdown

Here is a summary of the commands.

For all the commands taking an executable the executable is expected to be a binary using V8. If no executable is specified the release mode V8 shell is assumed.

By default the --session-dir=/tmp/oprofv8 is passed to all oprofile commands. This walue can be changed by setting environment variable OPROFILE_SESSION_DIR.

When using the defaulf executable (V8 shell in release mode) it is assumed to be located in ../.. relative from the oprofile utility scripts. This default location can be overridden using the V8_SHELL_DIR environment variable.

start
-----
Start the oprofiling daemon.

run [executable] [parameters]
-----------------------------
Profile a V8 executable. Running this will reset oprofile samples, run the command and do an oprofile dump to flush samples and write ELF binaries for the generated code. The parameters are passed to the executable together with the --oprofile option.

report [executable] [parameters]
--------------------------------
Print the report for a profile run. The parameters are passed to opreport. E.g report --callgraph.

annotate [executable] [parameters]
----------------------------------
Print annotated assembly for a profile run. The parameters are passed to opannotate. E.g annotate -threshold 1.

reset
-----
Reset oprofile samples.

dump
----
Flush oprofile samples and write ELF binaries for the generated code.

shutdown
--------
Shutdown oprofile daemon.

Added a warning which is printed if option --oprofile is passed to a V8 which has not been compiled with oprofile support.
Review URL: http://codereview.chromium.org/125181

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2186 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      78a8cdfb
  19. 08 Jun, 2009 1 commit
  21. 05 Jun, 2009 2 commits
  23. 04 Jun, 2009 2 commits
  25. 03 Jun, 2009 1 commit
  27. 28 May, 2009 1 commit
    • mikhail.naganov@gmail.com's avatar
      Implement a dynamically growing memory log buffer with an upper limit. · e48095b8
      mikhail.naganov@gmail.com authored 
      The goal of this change is to allow longer profiling sessions and preserve memory when profiler isn't started. The buffer starts with 64K and grows until it reaches the upper limit, which is currently set to 50MB --- according to my evaluations, this is enough for at least 20 minutes of GMail profiling. As we're planning to introduce compression for the profiler log, this time boundary will be significantly increased soon.

To make possible unit testing of the new component, I've factored out Logger's utility classes into a separate source file: log-utils.h/cc. Log and LogMessageBuilder are moved there from log.cc without any semantical changes.

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


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      e48095b8
  29. 22 May, 2009 1 commit
  31. 20 May, 2009 1 commit
  33. 14 May, 2009 4 commits
  35. 12 May, 2009 1 commit
  37. 08 May, 2009 1 commit
  39. 05 May, 2009 2 commits
  41. 30 Apr, 2009 3 commits
  43. 29 Apr, 2009 2 commits