The current profiling mode (called kLeafNodeLineNumbers in this CL)
produces a tree, with each node representing a stack frame that is seen
in one or more samples taken during profiling. These nodes refer to a
particular function in a stack trace, but not to a particular line or
callsite within that function.
This CL adds a new more (called kCallerLineNumbers) which produces a
different profile tree, where each stack trace seen during profiling,
including the line number, has a unique path in the tree.
The profile tree was previously keyed on CodeEntry*. Now it is keyed on
the pair of CodeEntry* and line_number, meaning it has distinct nodes
for those combinations which exist, and each distinct stack trace that
was sampled is represented in the tree.
For optimized code where we have inline frames, there are no line
numbers for the inline frames in the stack trace, causing duplicate
branches in the tree with kNoLineNumberInfo as the reported line number.
This will be addressed in follow-ups.
Bug: v8:7018
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I512e221508f5b50ec028306d212263b514a9fb24
Reviewed-on: https://chromium-review.googlesource.com/1013493
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53298}
Currently ProfilerListener holds all the CodeEntries it ever
created during the profiling session. It is not capable of removing
entries corresponding to the code objects discarded by GC as there's
no such code event.
However it is sometimes possible to tell if a code object was GCed.
Hook up to the CodeMap code entry removal and if the entry has never
been hit by a sample we can safely delete it.
As a bonus the CodeEntryInfo size has been reduced on x64, which also
saves 8 x <number of code entries> bytes.
BUG=v8:7719
Change-Id: I988bc5b59f3fba07157a9f472cbcf68596fcd969
Reviewed-on: https://chromium-review.googlesource.com/1054346
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53222}
The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.
Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
Remove comment about usage of FATAL, UNREACHABLE and UNIMPLEMENTED,
which was deprecated since https://crrev.com/1410713006.
Also, refactor the FATAL macro and use it for implementing UNREACHABLE
and UNIMPLEMENTED, and in more code. The benefit over printf +
CHECK(false) is that the compiler knows that FATAL will never return.
R=bmeurer@chromium.org
Change-Id: I8c2ab3b4e6edfe8eff5ec6fdf3d92b15d0ed7126
Reviewed-on: https://chromium-review.googlesource.com/832726
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50183}
New code should use nullptr instead of NULL.
This patch updates existing use of NULL to nullptr where applicable,
making the code base more consistent.
BUG=v8:6928,v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c
Reviewed-on: https://chromium-review.googlesource.com/718338
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48557}
By adding a per test source file namespace, we can avoid a lot of
symbol collisions in jumbo builds.
While we're at it, let's remove some "using" statements that also
cause trouble.
Bug: chromium:746958
Change-Id: I6f8a723e1ba5905888638e0687b23193f3f012ca
Reviewed-on: https://chromium-review.googlesource.com/676803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48102}
As part of J2V8 development (https://github.com/eclipsesource/J2V8),
we realized that we had a subtle bug in how Isolate scope was created
and it's lifetime managed, see:
https://github.com/eclipsesource/J2V8/issues/313.
Mentioned above bug was fixed, however, what we also noticed is that
V8 API has been constantly and slowly moving to such an API, in which
one has to pass Isolate explicitly to methods and/or constructors. We
found two more places that might have been overlooked. This contribution
adds passing of Isolate pointer explicitly to constructors of
String::Utf8Value and String::Value classes.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I61984285f152aba5ca922100cf3df913a9cb2cea
Reviewed-on: https://chromium-review.googlesource.com/593309
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47656}
With TurboFan, there should no longer be any deopt loops (aside from
bugs). So, the "too many deopts" bailout is no longer needed, at least
in its current form.
This fixes an issue where deopt counts are leaked between native
contexts, resulting in optimization being disabled unnecessarily.
Bug: v8:6402
Change-Id: Ia06374ae6b5c2d473bcdd8eef1284bf02766c2fb
Reviewed-on: https://chromium-review.googlesource.com/588894
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46961}
These are no longer necessary since we only have one optimizing compiler.
Also avoid changing --turbo-filter when --no-opt is set, and instead
explicitly check both the FLAG_opt and FLAG_turbo_filter in
GetOptimizedCode to check whether optimization is disabled.
BUG=v8:6408
Change-Id: I0948f788e8ff111c08022270d86c22f848da300a
Reviewed-on: https://chromium-review.googlesource.com/568484
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46648}
This removes the ability of the compilation pipeline to invoke the
Crankshaft optimizing compiler for JavaScript functions. Note that in
this state Crankshaft can still be used to compile code stubs.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0bec7c8ec7c705c13257df43796403a228ea631c
Reviewed-on: https://chromium-review.googlesource.com/527443
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45803}
Currently we count optimizations to decide to disable optimization, and
count deopts to detect this decision and allow re-enabling optimizations
after a while.
However, throwing out TurboFan OSR code and GC optimized code evictions
do not count as deopts, which means that the optimization count
increases without increasing the deopt count. This increased optimization
count disables further optimization -- which is bad, because these are
not "true" deopts -- and can stop the optimization from being re-enabled,
because the deopt count can't go high enough.
Instead, we now only ever look at deopts to disable/re-enable
optimization, and opt counts are only used for naming log files and in
tests.
Change-Id: I0c7d6be497545449a38cf952cd2f007ee51982ba
Reviewed-on: https://chromium-review.googlesource.com/468811
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44647}
Downside: this adds all kinds of weird includes in the .cc files.
(See design doc linked in the bug.)
BUG=v8:5402
Review-Url: https://codereview.chromium.org/2622503002
Cr-Commit-Position: refs/heads/master@{#42140}
These are added to the sampler stack trace when RCS are
enabled.
Resource name for a RCS frame is reported as "V8Runtime".
Counter names match ones from src/counters.h
BUG=chromium:660428
Review-Url: https://codereview.chromium.org/2461003002
Cr-Commit-Position: refs/heads/master@{#40658}
Rebuilding (after touching certain files) is crazy slow because
includes are out of control. Many of these files we need to rebuild are
cctests which pull in more includes than they need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2304553002
Cr-Commit-Position: refs/heads/master@{#39080}
Isolate is not going to retain a CPU profiler.
The client will be creating an instance of profiler when needed.
Deprectate v8::Isolate::GetCpuProfiler()
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2117343006
Cr-Commit-Position: refs/heads/master@{#37613}
Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
from Logger, constructs and stores CodeEventsContainer. This patch is part of
the effort to split the logic of CodeEventListener as ProfilerListener out of
the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
to code events, construct code event to CodeEventsContainer and pass it to code
event handler.
The reason we refactor CpuProfiler is that eventually we want to move
CpuProfiler as part of sampler library and code event listener should stay
inside V8.
Main changes:
1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
functionality and the ProfilerListener listening to code events from Logger.
2. Created CodeEventObserver and made CpuProfiler inherit from it.
ProfilerListener will have a list of observers and call CodeEventHandler once a
code event is created.
3. Moved code entry list from CodeEntry to ProfilerListener.
Minor changes:
1. Moved static code entry as part of CodeEntry.
2. Added ProfilerListener to Logger.
BUG=v8:4789
Committed: https://crrev.com/cb59fc1facc9b390e2c7544b4da56a4e0a9b3222
Review-Url: https://codereview.chromium.org/2053523003
Cr-Original-Commit-Position: refs/heads/master@{#37112}
Cr-Commit-Position: refs/heads/master@{#37195}
Reason for revert:
MIPS compilation error.
Original issue's description:
> Refactor CpuProfiler.
>
> Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
> from Logger, constructs and stores CodeEventsContainer. This patch is part of
> the effort to split the logic of CodeEventListener as ProfilerListener out of
> the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
> to code events, construct code event to CodeEventsContainer and pass it to code
> event handler.
>
> The reason we refactor CpuProfiler is that eventually we want to move
> CpuProfiler as part of sampler library and code event listener should stay
> inside V8.
>
> Main changes:
> 1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
> functionality and the ProfilerListener listening to code events from Logger.
> 2. Created CodeEventObserver and made CpuProfiler inherit from it.
> ProfilerListener will have a list of observers and call CodeEventHandler once a
> code event is created.
> 3. Moved code entry list from CodeEntry to ProfilerListener.
>
> Minor changes:
> 1. Moved static code entry as part of CodeEntry.
> 2. Added ProfilerListener to Logger.
>
> BUG=v8:4789
>
> Committed: https://crrev.com/cb59fc1facc9b390e2c7544b4da56a4e0a9b3222
> Cr-Commit-Position: refs/heads/master@{#37112}
TBR=alph@chromium.org,jochen@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2079273003
Cr-Commit-Position: refs/heads/master@{#37113}
Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
from Logger, constructs and stores CodeEventsContainer. This patch is part of
the effort to split the logic of CodeEventListener as ProfilerListener out of
the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
to code events, construct code event to CodeEventsContainer and pass it to code
event handler.
The reason we refactor CpuProfiler is that eventually we want to move
CpuProfiler as part of sampler library and code event listener should stay
inside V8.
Main changes:
1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
functionality and the ProfilerListener listening to code events from Logger.
2. Created CodeEventObserver and made CpuProfiler inherit from it.
ProfilerListener will have a list of observers and call CodeEventHandler once a
code event is created.
3. Moved code entry list from CodeEntry to ProfilerListener.
Minor changes:
1. Moved static code entry as part of CodeEntry.
2. Added ProfilerListener to Logger.
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2053523003
Cr-Commit-Position: refs/heads/master@{#37112}
The patch introduces a dedicated dispatching class for JIT code events. It is
set as a helper on the isolate.
This allows classes across v8 to break their dependency on Logger and CpuProfiler.
These two became just regular clients of the dispatcher.
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2061623002
Cr-Commit-Position: refs/heads/master@{#37005}
Makes --ignition cause eager compilation if we aren't building the startup
snapshot.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1811553003
Cr-Commit-Position: refs/heads/master@{#35066}
Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.
The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.
Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.
Still to do is tracking source positions which will be done in a
followup CL.
BUG=v8:4766
LOG=N
Review URL: https://codereview.chromium.org/1728593002
Cr-Commit-Position: refs/heads/master@{#34321}
This is in preparation to enabling --turbo-inlining by default, fixing
various issues when general purpose inlining is running against our
entire test suite.
R=bmeurer@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1407533004
Cr-Commit-Position: refs/heads/master@{#31294}
This is an adaptation of test-profile-generator/BailoutReason to when
try-catch statements are optimizable. They will no longer cause any
bailout reason to be reported.
R=yangguo@chromium.org
TEST=cctest/test-profile-generator/BailoutReason
Review URL: https://codereview.chromium.org/1213113007
Cr-Commit-Position: refs/heads/master@{#29440}
