This reverts commit 64f1200593.
Revert "Bug 1881627: HiResWindowsMonitor switches between hi- and lo-res timers depending on the tolerance of the wait. r=smaug,gstoll"
This reverts commit b26c5e86c4.
Revert "Bug 1881627: Compute wait delay tolerance in TimerThread r=smaug"
This reverts commit 35fff48605.
Revert "Bug 1881627: Implemented HiResWindowsMonitor and used it in TimerThread (on Windows) r=smaug"
This reverts commit 9a0f2b30a0.
Revert "Bug 1881627: Templated *MonitorAuto* r=smaug"
This reverts commit 695384e7e0.
Revert "Bug 1881627: Got rid of WindowsTimerFrequencyManager and related machinery r=smaug"
This reverts commit 2f1747630b.
The linear scan for the insertion point can be replaced by a binary search.
All the other logic of finding empty slots or removing entries remains unchanged by this.
Resulting complexity:
- Changed: AddTimer becomes minimum O(log[n]) (due to the lower boundary of the binary search) to maximum O(n) depending on the luck we have with finding empty slots.
- Changed: RemoveTimer becomes O(log(n)) always (for the binary search) as we postpone the removal of canceled timers to happen in the Run loop or through re-use.
- Extracting the next timer to fire on the TimerThread remains always O(n) (but happens on the timer thread, where it might disturb less).
- Removing the leading canceled timers remains always O(n) (but happens on the timer thread, where it might disturb less).
Differential Revision: https://phabricator.services.mozilla.com/D249902
Entry's lifecycle was strictly bound to (Set)IsInTimerThread. It can become a simple struct which will ease its handling in sorted arrays (or sets).
We simply make explicit calls to SetIsInTimerThread where the add/remove occurs.
AddTimerInternal's many if clauses can be re-arranged in a simpler loop, the way of re-using empty slots should be unchanged by this. This enables us also to not need the ctor for canceled timers in Entry.
Note also that the single loop with swap is faster than scanning first for empty slots and in the not unlikely case of no empty slots moving the tail of timers then.
Differential Revision: https://phabricator.services.mozilla.com/D249901
This will help us later to craft stable and unique sort conditions for TimerThread::mTimers, enabling binary search on the array.
Differential Revision: https://phabricator.services.mozilla.com/D249899
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
The linear scan for the insertion point can be replaced by a binary search.
All the other logic of finding empty slots or removing entries remains unchanged by this.
Resulting complexity:
- Changed: AddTimer becomes minimum O(log[n]) (due to the lower boundary of the binary search) to maximum O(n) depending on the luck we have with finding empty slots.
- Changed: RemoveTimer becomes O(log(n)) always (for the binary search) as we postpone the removal of canceled timers to happen in the Run loop or through re-use.
- Extracting the next timer to fire on the TimerThread remains always O(n) (but happens on the timer thread, where it might disturb less).
- Removing the leading canceled timers remains always O(n) (but happens on the timer thread, where it might disturb less).
Differential Revision: https://phabricator.services.mozilla.com/D249902
Entry's lifecycle was strictly bound to (Set)IsInTimerThread. It can become a simple struct which will ease its handling in sorted arrays (or sets).
We simply make explicit calls to SetIsInTimerThread where the add/remove occurs.
AddTimerInternal's many if clauses can be re-arranged in a simpler loop, the way of re-using empty slots should be unchanged by this. This enables us also to not need the ctor for canceled timers in Entry.
Note also that the single loop with swap is faster than scanning first for empty slots and in the not unlikely case of no empty slots moving the tail of timers then.
Differential Revision: https://phabricator.services.mozilla.com/D249901
This will help us later to craft stable and unique sort conditions for TimerThread::mTimers, enabling binary search on the array.
Differential Revision: https://phabricator.services.mozilla.com/D249899
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
- 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
Sylvestre Ledru