Without an explicit check if a function belongs to shared library address space, "finishing" a library symbols processing with 'addPrevEntry(libEnd);' can cause emission of code entries which cover almost the entire address space, shadowing other code.
Review URL: http://codereview.chromium.org/131033
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2221 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
This is a trivial per-row compression:
- short aliases are introduced for events and code creation tags;
- in tick events, offsets are used instead of absolute addresses;
- removed 'code-allocation' event, as it seems not used.
The first two options are depend on the new flag: 'compress-log', which is off by default.
On benchmarks run w/o snapshot, this gives 45% log size reduction.
Review URL: http://codereview.chromium.org/119304
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Change stack alignment on linux to 16 bytes to keep gcc 4.4 happy.
This fixes the mksnapshot segfault without requiring -fno-tree-vectorize
which just avoided the problem by not generating code with movdqa.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2107 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
encoding the values in one word and by using an indirection table for
handles.
This reduces compilation time by roughly 10% and we should be able to make the slow case equality checking of frame elements faster as well.
Review URL: http://codereview.chromium.org/115347
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1949 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This will enable reading profiler log in Chrome. The current implementation of memory buffer is trivial (fixed size buffer, no memory recycling) but enough to start end-to-end DevTools Profiler implementation. Later it will be enhanced.
Review URL: http://codereview.chromium.org/108011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1870 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- TARGET, the architecture we will generate code for.
This is brought it from the build system.
- HOST, the architecture our C++ compiler is building for.
This is detected automatically based on compiler defines.
This adds macros for 32 or 64 bit, and cleans up some
include conditionals, etc.
Review URL: http://codereview.chromium.org/99355
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1864 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current version is now held in src/version.cc in a number of defines which needs to be modified when changing version.
The following defines make up the version information:
MAJOR_VERSION
MINOR_VERSION
BUILD_NUMBER
PATCH_LEVEL
CANDIDATE_VERSION
The first four are numbers and the fifth is a boolean. Besides these five the define
SONAME
can be used to set a specific soname when building the a shared library (see below). This will most likely be used on stable branches where binary compatibility is ensured between different versions. This define is a string.
This version information is now read by the SCons build to support setting the soname for a Linux shared library. This requires passing the option soname=on to the SCons build.
When soname=on is specified the soname for the shared library can be set in two different ways. Either it will be the full versioned library name (e.g. libv8-1.2.2.so) or a specific soname defined in src/version.cc. Whenever a shared library is build with an soname the filename of the library will hold the full version name (e.g. libv8-1.2.2.so).
I did not update the xcode project with the new files.
BUG=151
Review URL: http://codereview.chromium.org/100104
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1826 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
Gyp is used to generate project files used to build chromium. Moving
the v8.gyp file to the v8 repository makes it easier to have V8 and
the v8.gyp file synchronized (so a DEPS update in chromium gets the
right v8.gyp file associated with that revision of V8).
Review URL http://codereview.chromium.org/100035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1795 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is the first step in reimplementing tick processing scripts in
JavaScript. The goal is to have the same source both for Dev Tools and
Golem, so Python implementation will be removed to avoid code
duplication.
The implementation follows the Dev Tools style: namespaces and JSDocs
are used.
Review URL: http://codereview.chromium.org/67151
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently function name inference is wired with AST optimization pass to avoid introducing another pass over AST. A better solution would be to rewrite AST visitors so they can be naturally combined together in a single pass, as their current implementation doesn't allow it.
For examples of cases where function names can be inferred, see the tests file.
Review URL: http://codereview.chromium.org/62146
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1696 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix exception propagation problem where undefined was returned instead
of an empty handle in case of an exception. This problem can break
C++ programs that are not interested in catching exceptions and just
want to propagate them out by testing for empty handles.
The issue is that exceptions are not rescheduled if they are
externally caught. Externally caught exceptions have to be
rescheduled if there is a JavaScript frame on the way to the C++ frame
that holds the external handler.
A couple of tests will fail on the ARM simulator because the simulator
has separate stacks for C++ and JavaScript. I have marked the tests
as failing only on the simulator.
Review URL: http://codereview.chromium.org/56105
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1657 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
