It's a wafer thin wrapper around profiler_tracing() and it's only used three
times. Let's just remove it.
Note also that those three uses are the only places where TRACING_EVENT is
used. I wonder if they're really needed...
--HG--
extra : rebase_source : ac70b4c77c4592d96957a8e6249597eafc822fd4
This removes LUL's ability to recover frames by the heuristic mechanism of
stack scanning. Stack scanning is a last-ditch way to try to recover the
unwind when all other methods (metadata-based, frame-pointer chasing) have
failed, by scanning back up the stack and looking for the first word that
could plausibly be a return address. It often mis-identifies return addresses
because it has no way to distinguish live ones from dead ones that have not
been overwritten, and very often causes the unwind to fail as a result.
In any case LUL's stack scanning ability has actually been switched off (by
the parameters passed to LUL::Unwind) for some considerable time now, so this
change should make no observable difference to behaviour. Specific changes:
In LUL::Unwind():
* Removes formal parameters |scannedFramesAcquired| and |scannedFramesAllowed|
* Removes code that does stack scanning
* Simplifies control flow in the main unwind loop, so that loop now
has the easier-to-follow structure
while (true) {
// preliminary stuff
if (CFI data available for current PC) {
do CFI step;
continue;
}
if (FP chasing possible for current PC) {
do FP step;
continue;
}
// give up
break;
}
* Moves two #ifdefs upwards to enclose the comments pertaining to them, as
well as the code. This makes the top level structure easier to follow. The
corresponding #endifs are likewise commented with the condition.
From class LULStats, removes |mScanned|.
Removes PriMap::MaybeIsReturnPoint() entirely. This is a heuristic helper
only used by stack scanning.
In all, 395 lines of code are removed, according to hg diff --stat.
--HG--
extra : rebase_source : 5ffa73c64923149a58df3228cf940cb539f8f707
We rely partly on the constructor to set Registers, and partly on subsequent
assignments. This patch changes things so we rely entirely on subsequent
assignments, for consistency.
--HG--
extra : rebase_source : ca69186f5755003e710985bfb40c90072067305c
We can use a static ucontext_t on Linux for synchronous samples instead of
declaring one on the stack in profiler_get_backtrace(). This neatens
SyncPopulate()'s signature.
SyncPopulate() is also only used when HAVE_NATIVE_UNWIND is defined, so the
patch guards the definitions.
--HG--
extra : rebase_source : b71e6d76f24b37bc236ac8f4359d401b1551e2de
The patch:
- Removes some unnecessary forward declarations.
- Moves some macros to more logical locations.
- Improves and removes some comments.
--HG--
extra : rebase_source : 23f1de029bbe4a37d2cc1ebe1df76e9a6aa1b335
It's bugged me for some time that the comments explaining what all the
PROFILER_* macros do are on the empty definitions that are used when the
profiler is disabled. This patch switches the order.
--HG--
extra : rebase_source : d783aa996f91b305cbebd678e6652d6bc939fb98
This patch does the following.
- Renames some ProfilerMarkerPayload subclasses so they all of the form
"FooMarkerPayload", to make the subclass relationship clearer.
(ProfilerMarkerTracing -- now TracingMarkerPayload -- was the worst
offender.)
- Removes ProfilerMarkerImagePayload and TouchDataPayload, neither of which are
used.
- Changes streamCommonProps() to StreamCommonProps().
- Does some minor style and comment fixes in ProfilerMarkerPayload.h.
--HG--
extra : rebase_source : dd732905e96da83bcbf124c70b20011c661fc332
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
Bug 1357829 added a third kind of sample, in addition to the existing
"periodic" and "synchronous" samples. This patch cleans things up around that
change. In particular, it cleans up TickSample, which is a mess of semi-related
things.
The patch does the following.
- It removes everything from TickSample except the register values and renames
TickSample as Registers. Almost all the removed stuff is available in
ThreadInfo anyway, and the patch adds a ThreadInfo argument to various
functions. (Doing it this way wasn't possible until recently because a
ThreadInfo wasn't available in profiler_get_backtrace() until recently.)
One non-obvious consequence: in synchronous samples we used to use a value of
0 for the stackTop. Because synchronous samples now use ThreadInfo directly,
they are able to use the proper stack top value from ThreadInfo::mStackTop.
This will presumably only improve the quality of the stack traces.
- It splits Tick() in two and renames the halves DoPeriodicSample() and
DoSyncSample().
- It reorders arguments in some functions so that ProfileBuffer (the output) is
always last, and inputs are passed in roughly the order they are obtained.
- It adds a comment at the top of platform.cpp explaining the three kinds of
sample.
- It renames a couple of other things.
--HG--
extra : rebase_source : 4f1e69c605102354dd56ef7af5ebade201e1d106
The source of truth for this list is in the PROFILER_FOR_EACH_FEATURE macro.
MozReview-Commit-ID: 13qppZKVi1r
--HG--
extra : rebase_source : 8f1ffdada1f73d2659ca9ed676be2fd3783e27f6
Bug 1357829 added a third kind of sample, in addition to the existing
"periodic" and "synchronous" samples. This patch cleans things up around that
change. In particular, it cleans up TickSample, which is a mess of semi-related
things.
The patch does the following.
- It removes everything from TickSample except the register values and renames
TickSample as Registers. Almost all the removed stuff is available in
ThreadInfo anyway, and the patch adds a ThreadInfo argument to various
functions. (Doing it this way wasn't possible until recently because a
ThreadInfo wasn't available in profiler_get_backtrace() until recently.)
One non-obvious consequence: in synchronous samples we used to use a value of
0 for the stackTop. Because synchronous samples now use ThreadInfo directly,
they are able to use the proper stack top value from ThreadInfo::mStackTop.
This will presumably only improve the quality of the stack traces.
- It splits Tick() in two and renames the halves DoPeriodicSample() and
DoSyncSample().
- It reorders arguments in some functions so that ProfileBuffer (the output) is
always last, and inputs are passed in roughly the order they are obtained.
- It adds a comment at the top of platform.cpp explaining the three kinds of
sample.
- It renames a couple of other things.
--HG--
extra : rebase_source : 61f4bf75ff5a2c331e8e39dcbb2bf3563606ebb0
This patch performs a refactoring to the internals of the profiler in order to
expose a function, profiler_suspend_and_sample_thread, which can be called from a
background thread to suspend, sample the native stack, and then resume the
target passed-in thread.
The interface was designed to expose as few internals of the profiler as
possible, exposing only a single callback which accepts the list of program
counters and stack pointers collected during the backtrace.
A method `profiler_current_thread_id` was also added to get the thread_id of the
current thread, which can then be passed by another thread into
profiler_suspend_sample_thread to sample the stack of that thread.
This is implemented in two parts:
1) Splitting SamplerThread into two classes: Sampler, and SamplerThread.
Sampler was created to extract the core logic from SamplerThread which manages
unix signals on android and linux, as well as suspends the target thread on all
platforms. SamplerThread was then modified to subclass this type, adding the
extra methods and fields required for the creation and management of the actual
Sampler Thread.
Some work was done to ensure that the methods on Sampler would not require
ActivePS to be present, as we intend to sample threads when the profiler is not
active for the Background Hang Reporter.
2) Moving the Tick() logic into the TickController interface.
A TickController interface was added to platform which has 2 methods: Tick and
Backtrace. The Tick method replaces the previous Tick() static method, allowing
it to be overridden by a different consumer of SuspendAndSampleAndResumeThread,
while the Backtrace() method replaces the previous MergeStacksIntoProfile
method, allowing it to be overridden by different consumers of
DoNativeBacktrace.
This interface object is then used to wrap implementation specific data, such as
the ProfilerBuffer, and is threaded through the SuspendAndSampleAndResumeThread
and DoNativeBacktrace methods.
This change added 2 virtual calls to the SamplerThread's critical section, which
I believe should be a small enough overhead that it will not affect profiling
performance. These virtual calls could be avoided using templating, but I
decided that doing so would be unnecessary.
MozReview-Commit-ID: AT48xb2asgV
Profiler labels can't currently be used in mozglue, because the profiler's code
is in libxul, and mozglue cannot depend on libxul.
This patch addresses this by basically duplicating AutoProfilerLabel in
mozglue. libxul passes two callback functions to mozglue to do the actual
pushing/popping of labels.
It's an annoying amount of machinery, but it is unavoidable if we want to use
profiler labels within mozglue.
--HG--
extra : rebase_source : 4bcb6fb0f050bba42c23d92d01f9c56611f8518f
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
This patch puts the arrays inside NativeStack, gives NativeStack a constructor,
and renames its fields using "mFoo" form.
The patch also moves MAX_NATIVE_FRAMES from the LUL-only code and applies it
globally. This increases the max native frame count from 256 to 1024 on the
LUL platforms, which makes things consistent with other platforms.
--HG--
extra : rebase_source : 0854ab37d101e090ea05cba7cb6d296450f8dfdc
This increases naming consistency. The remaining aStartTime parameters within
the profiler refer to a different start time than the process start time.
--HG--
extra : rebase_source : 0a07c54288f31af5a15518180b00fe59b587f784
ProfilerStackFrameRAII and ProfilerStackFrameDynamicRAII are very similar; the
latter lets a dynamic string be specified as well (and lacks the
MOZ_GUARD_OBJECT stuff, for no good reason).
This patch does the following.
- Removes ProfilerStackFrameDynamicRAII, and adds a dynamic string to
ProfilerStackFrameRAII. It also reorders the constructor's arguments to match
the field ordering of ProfileEntry. There aren't many usage sites so these
changes don't affect many places.
- With that done, there is only a single callsite for each of
profiler_call_enter() and profiler_call_exit(), so the patch also inlines and
removes them.
These annotations aren't doing anything useful. The important thing with
the PseudoStack is that, during pushes, the stack pointer incrementing happens
after the new entry is written, and this is ensured by the stack pointer being
Atomic.
The patch also improves the comments on PseudoStack.
--HG--
extra : rebase_source : 100f8a5e4b750c15fac66175550c4c284a141f16
There are three flags in ProfileEntry::Flags, which suggests there are 2**3 = 8
combinations. But there are only actually 4 valid combinations.
This patch converts the three flags to a single "kind" enum, which makes things
clearer. Note also that the patch moves the condition at the start of
AddPseudoEntry() to its callsite, for consistency with the earlier JS_OSR entry
kind check.
--HG--
extra : rebase_source : 0950769ee1530291860ef3be47d240df5939e871
The category handling code at the end of AddPseudoEntry has two problems.
- The assertion checks |category| for the IS_CPP_ENTRY flag. This represents a
confusion between the entry's |category| and its |flags|. They're both stored
in a single uint32_t, but are conceptually different types. So the assertion
is vacuously satisfied.
Furthermore, there's no clear way to fix the assertion -- it doesn't make
sense to check the entry's flags for IS_CPP_ENTRY, because this code can
clearly take C++ or JS entries. So the patch just removes the assertion.
- The category is compared to zero. This also doesn't make sense, because zero
isn't a valid category. The patch removes this comparison.
--HG--
extra : rebase_source : 16a7248ffb90ccd90e6102d597fb5bdff706312e
Nicholas Nethercote
Carsten "Tomcat" Book
Julian Seward
Bill McCloskey
Markus Stange
Phil Ringnalda
Michael Layzell
Tom Tromey
Sylvestre Ledru