| BackgroundHangMonitor.cpp |
BackgroundHangManager is the global object that
manages all instances of BackgroundHangThread.
|
25972 |
| BackgroundHangMonitor.h |
The background hang monitor is responsible for detecting and reporting
hangs in main and background threads. A thread registers itself using
the BackgroundHangMonitor object and periodically calls its methods to
inform the hang monitor of the thread's activity. Each thread is given
a thread name, a timeout, and a maximum timeout. If one of the thread's
tasks runs for longer than the timeout duration but shorter than the
maximum timeout, a (transient) hang is reported. On the other hand, if
a task runs for longer than the maximum timeout duration or never
finishes (e.g. in a deadlock), a permahang is reported.
Tasks are defined arbitrarily, but are typically represented by events
in an event loop -- processing one event is equivalent to running one
task. To ensure responsiveness, tasks in a thread often have a target
running time. This is a good starting point for determining the timeout
and maximum timeout values. For example, the Compositor thread has a
responsiveness goal of 60Hz or 17ms, so a starting timeout could be
100ms. Considering some platforms (e.g. Android) can terminate the app
when a critical thread hangs for longer than a few seconds, a good
starting maximum timeout is 4 or 5 seconds.
A thread registers itself through the BackgroundHangMonitor constructor.
Multiple BackgroundHangMonitor objects can be used in one thread. The
constructor without arguments can be used when it is known that the thread
already has a BackgroundHangMonitor registered. When all instances of
BackgroundHangMonitor are destroyed, the thread is unregistered.
The thread then uses two methods to inform BackgroundHangMonitor of the
thread's activity:
> BackgroundHangMonitor::NotifyActivity should be called *before*
starting a task. The task run time is determined by the interval
between this call and the next NotifyActivity call.
> BackgroundHangMonitor::NotifyWait should be called *before* the
thread enters a wait state (e.g. to wait for a new event). This
prevents a waiting thread from being detected as hanging. The wait
state is automatically cleared at the next NotifyActivity call.
The following example shows hang monitoring in a simple event loop:
void thread_main()
{
mozilla::BackgroundHangMonitor hangMonitor("example1", 100, 1000);
while (!exiting) {
hangMonitor.NotifyActivity();
process_next_event();
hangMonitor.NotifyWait();
wait_for_next_event();
}
}
The following example shows reentrancy in nested event loops:
void thread_main()
{
mozilla::BackgroundHangMonitor hangMonitor("example2", 100, 1000);
while (!exiting) {
hangMonitor.NotifyActivity();
process_next_event();
hangMonitor.NotifyWait();
wait_for_next_event();
}
}
void process_next_event()
{
mozilla::BackgroundHangMonitor hangMonitor();
if (is_sync_event) {
while (!finished_event) {
hangMonitor.NotifyActivity();
process_next_event();
hangMonitor.NotifyWait();
wait_for_next_event();
}
} else {
process_nonsync_event();
}
}
|
6893 |
| BHRTelemetryService.sys.mjs |
|
4789 |
| components.conf |
|
686 |
| HangAnnotations.cpp |
|
2955 |
| HangAnnotations.h |
This class extends nsTArray<HangAnnotation> with some methods for adding
annotations being reported by a registered hang Annotator.
|
2093 |
| HangDetails.cpp |
|
23653 |
| HangDetails.h |
HangDetails is the concrete implementaion of nsIHangDetails, and contains the
infromation which we want to expose to observers of the bhr-thread-hang
observer notification.
|
3091 |
| HangTypes.ipdlh |
|
2363 |
| moz.build |
|
1799 |
| nsIHangDetails.idl |
A scriptable interface for getting information about a BHR detected hang.
This is the type of the subject of the "bhr-thread-hang" observer topic.
|
2180 |
| tests |
|
|
| ThreadStackHelper.cpp |
|
13297 |
| ThreadStackHelper.h |
ThreadStackHelper is used to retrieve the profiler's "profiling stack" of a
thread, as an alternative of using the profiler to take a profile.
The target thread first declares an ThreadStackHelper instance;
then another thread can call ThreadStackHelper::GetStack to retrieve
the profiling stack of the target thread at that instant.
Only non-copying labels are included in the stack, which means labels
with custom text and markers are not included.
|
3569 |