Name Description Size
BHRTelemetryService.jsm 4940
BackgroundHangMonitor.cpp BackgroundHangManager is the global object that manages all instances of BackgroundHangThread. 27632
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
HangAnnotations.cpp 2955
HangAnnotations.h This class extends nsTArray<HangAnnotation> with some methods for adding annotations being reported by a registered hang Annotator. 2077
HangDetails.cpp 22742
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. 3070
HangTypes.ipdlh 2368
ThreadStackHelper.cpp 12573
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. 3445
components.conf 677
moz.build 1638
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. 2177
tests 4