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: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52723}
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}
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
'nm' is now called with an option to report function code sizes. Static code entries are restricted to the sizes reported, and the remaining unnamed code is attributed to a library as a whole. This makes reports more accurate, as some functions are tiny, but has chunks of unnamed code behind them.
This change doesn't affect reporting on Windows, as in .map files function code sizes aren't specified.
Review URL: http://codereview.chromium.org/149513
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2455 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
