- 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/+/2016586
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66145}
If profiling is done with --log-source-code profview will now display
a "View source" link for each function in the tree view. Clicking this
will show a new source viewer, with sampled lines highlighted. See the
associated bug for screenshots.
This patch also fixes a bug in the profiler where the source info of
only the first code object for each function would be logged, and
includes some refactoring.
Bug: v8:6240
Change-Id: Ib96a9cfc54543d0dc9bef4657cdeb96ce28b223c
Reviewed-on: https://chromium-review.googlesource.com/1194231
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55542}
It appears that the fields are already being unescaped elsewhere,
perhaps by the JSON writer. So if we unescape when adding the source
filename and contents, unescaping will happen again later and plain
backslashes will be interpreted as escape codes.
Bug: v8:6240
Change-Id: Ic66b9017ae685d6dd12944ee8d254991e26fbd32
Reviewed-on: https://chromium-review.googlesource.com/1186625
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55401}
This also changes logging of code address to Code::instruction_start rather
than Code::address().
Bug: v8:6239
Change-Id: I4ef975630574e23409123468a3f7fb8fe6ad39e7
Reviewed-on: https://chromium-review.googlesource.com/605887
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47266}
Traditionally, we had a prefix for a function name of "~" for
unoptimized code and "*" for optimized code. Restore this prefix
in v8/tools/ic-processor. It's really cool to know if an IC was
called from optimized code (often a hint of poor performance!).
NOTRY=true
R=cbruni@chromium.org
Review-Url: https://codereview.chromium.org/2835923004
Cr-Commit-Position: refs/heads/master@{#44846}
This adds optimization and deoptimization counts to the Web UI. Also, the function timeline
now shows optimization and deoptimization marks.
Review-Url: https://codereview.chromium.org/2753543006
Cr-Commit-Position: refs/heads/master@{#44033}
In the tick processor, in cases where there are a lot of ticks (e.g.
long running programs), JSON.stringify could throw a range exception
because the created string is too large.
Instead of creating the entire JSON string in memory, we now write the
top-level parts of the JSON manually, writing out the ticks individually
instead of all together.
Review-Url: https://codereview.chromium.org/2754683002
Cr-Commit-Position: refs/heads/master@{#43973}
(1) --prof-cpp: Collects ticks like --prof, but ignores code creation events to reduce distortion (so all JS ticks will be "unaccounted"). Useful for profiling C++ code.
(2) --timed-range flag for tick processor: Ignores ticks before the first and after the last call to Date.now(). Useful for focusing on the timed section of a test.
Review URL: https://codereview.chromium.org/802333002
Cr-Commit-Position: refs/heads/master@{#26168}
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
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
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
'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
