Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
When runnables are posted to the main thread's event loop, the event
loop notifies any thread observers that this has been done. The app
shell registers itself as just such a runnable, and posts messages to
the native event loop that processing native events needs to be done.
On Windows, this posting takes an extra reference to the app shell, to
keep it alive until the message is processed by the native event loop,
since app shell code needs to be invoked during that processing. The
processing releases this extra reference, so everything stays balanced.
Except that it's possible for messages to be posted to the native event
loop, and then browser shutdown happens. Those messages are not
processed and the associated references taken are not released. This
imbalance means that in debug builds, we appear to be leaking the app
shell, and that leaking results in intermittent oranges.
This intermittent orange has manifested itself in a variety of ways over
the years, depending on how big the app shell itself was (since that
changes the number of bytes leaked) and how many leak-checked things the
app shell was holding on to. This bug is merely the latest
manifestation; the last serious work on analyzing the phenomenon and
fixing it was done in bug 1220517.
The solution proposed in that bug was that we simply stop the extra
reference counting; when the app shell is destroyed normally, we
shouldn't be processing the native event loop any more anyway. So even
if the native event loop is holding (freed) pointers to the app shell,
we'd never execute the callback and perform a use-after-free. Reading
through the code suggests that this *ought* to be the case, but the
potential for shooting ourselves in the foot seems awfully high.
In any event, this is not a problem unique to Windows; we have seen this
same sort of thing happen on OS X. See nsAppShell::ProcessGeckoEvents
in widget/cocoa/nsAppShell.mm.
Here we propose a slightly different solution: we keep track of the
number of native event callbacks we have scheduled, incrementing when we
schedule, and decrementing when we actually run one. When the app shell
is destroyed, we simply set the number of outstanding events to zero,
and we prohibit the callback from accessing the app shell if there are
no outstanding events. This solution is analogous to dropping the extra
reference counting, but avoids potential badness if we do wind up
processing native events after the app shell is destroyed.
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
We still get occasional messages for the internal OLE Main Thread window.
Also, the PeekMessage call allows internal windows messages to be processed for
things like GDI.
This does not remove the directives in widget/ContentCache.cpp as those crash
annotations should be temporary and will be removed once bug 1405832 is fixed.
MozReview-Commit-ID: F0STyYDx8F4
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
* OSX
Make the lock of the type kIOPMAssertionTypeNoDisplaySleep and kIOPMAssertionTypeNoIdleSleep
as a singleton. Won't need to require an extra lock.
* Windows
Add |mRequireForDisplay| to ensure the "audio-playing" won't overwrite the previous
display requirement.
* Android
Add "audio-playing" and "video-playing", and make sure the audio-lock won't be cancel
when receiving "WakeLockDelegate.STATE_LOCKED_BACKGROUND".
MozReview-Commit-ID: 97oNX7H2qij
For knowing the wake lock usage more clearly, we should use more specific topic name.
In OSX, you can use "$ pmset -g assertions" to check all the wakelock.
In Windows, using "$ powser -energy" to generate the energy report.
MozReview-Commit-ID: rAXnkxTvLc
billm reports that the runnable in this code is firing a lot, and since we
don't support XP/Vista we're not benefiting from this overhead.
MozReview-Commit-ID: Bpw1E9DxPpD
This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
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.
ScreenHelperWin is the platform dependent part of the original
nsScreenManagerWin and nsScreenWin. It listens the WM_DISPLAYCHANGE
message and pushes updates to ScreenManager. See patch part 4. for how
ScreenManager works.
MozReview-Commit-ID: 20A3ZQKmH9a
The new names make it clearer that these actions apply to just one thread.
- profiler_sleep_start() --> profiler_thread_sleep()
- profiler_sleep_end() --> profiler_thread_wake()
- profiler_is_sleeping() --> profiler_thread_is_sleeping()
- GeckoProfilerSleepRAII --> GeckoProfilerThreadSleepRAII
- GeckoProfilerWakeRAII --> GeckoProfilerThreadWakeRAII
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
