Given TimerThread::Entry contains a copy of the timeout, we can use that everywhere we have no lock on nsTimerImpl::mMutex, relying on the invariant that the timeout must not change while the timer is in the TimerThread.
Doing so enables us to annotate it and have stricter checks.
Note that one unsafe, DEBUG-only check remains but it is explicitly annotated as such. TSAN will tell if we are safe enough.
Differential Revision: https://phabricator.services.mozilla.com/D249898
The original intent of this DEBUG only function was to verify our book-keeping.
However, it prevents us from applying strict thread-safety checks on nsTimerImpl::mTimeout.
Given we are going to change our book-keeping up the stack, we can just remove it but:
- add an assertion directly before PostTimerEvent if the timeout remained unchanged
- add placeholder comments where to check for the correct sort order.
Differential Revision: https://phabricator.services.mozilla.com/D249897
Previously we would scale the wait time by a randomly selected factor,
which meant that small waits would only ever get small (probably
ineffective) adjustments. Now we randomly pick an adjustment in a known
range and build our adjustment from that. This is simple, and doesn't
require the costly, and otherwise unnecessary, conversion of a TimeStamp
to microseconds.
Differential Revision: https://phabricator.services.mozilla.com/D245678
Ultimately what the previous logic did was to affect what timers qualify
for "early firing" by sliding their firing time earlier or later (and
then using this new time to see if they fall inside or outside of the
allowed early firing window).
We can do this more simply by instead adjusting the early firing
tolerance and we also don't need to change it for every timer.
Differential Revision: https://phabricator.services.mozilla.com/D245677
The forceRunXXXTimer variables were used only when chaos mode was
enabled to implement some strange behavior that I don't want to preserve
in the upcoming refactor.
Differential Revision: https://phabricator.services.mozilla.com/D245676
The ThreadSafeAutoRefCnt takes care of the atomic fetch_sub that allows the calling thread to safely check for 0 without races.
Differential Revision: https://phabricator.services.mozilla.com/D244626
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
- Prior to this change, we allowed any timer *except* the first to fire early. Being woken up
slightly before our first timer is due was resulting in a lot of "wasted" wake-ups (where we wake
up and do nothing other than go back to sleep).
- This change results in waking up TimerThread 10% less frequently in my test case of watching a
YouTube video.
- Made the allowed early firing tolerance be a constant value rather than calculated at run-time.
- Also cleaned up some includes.
Differential Revision: https://phabricator.services.mozilla.com/D184017
- Prior to this change, we allowed any timer *except* the first to fire early. Being woken up
slightly before our first timer is due was resulting in a lot of "wasted" wake-ups (where we wake
up and do nothing other than go back to sleep).
- This change results in waking up TimerThread 10% less frequently in my test case of watching a
YouTube video.
- Made the allowed early firing tolerance be a constant value rather than calculated at run-time.
- Also cleaned up some includes.
Differential Revision: https://phabricator.services.mozilla.com/D184017
Jens Stutte