The previous version used IndexOfFirstElementGt which is implemented
with a binary search. That doesn't work correctly because the mTimers
array that is being searched is maintained in sorted order
*only if the "cancelled" timers are skipped*. This revision replaces the
binary search with a linear search which can handle this without
problem. Given that the number of timers present at any one time is
fairly modest, a linear search is probably a more appropriate choice
anyway.
Also added a new function, VerifyTimerListConsistency, which is called
once per wake-up in the main loop and enabled only in DEBUG builds, that
checks mTimers for ordering and consistency.
Differential Revision: https://phabricator.services.mozilla.com/D164294
This makes the code more complex, but it is needed to keep this most-used
function efficient related to its old implementation using `std::push_heap`.
Differential Revision: https://phabricator.services.mozilla.com/D164292
Inserting elements in the sorted array is more costly than pushing to a binary
heap, but this is balanced by the removal of indirections and de/allocations,
and the upcoming re-use of empty entries.
In the end, this change is necessary to allow future improvements like timer-
coalescing, where we'll need to see multiple timers in order.
Bonus: FindNextFireTimeForCurrentThread changes a lot, because it used to have
to `pop_heap` elements and then `push_heap` them back! (Sometimes resulting in
subtle changes for timers with the same timeout.) So this one benefits the
most.
Differential Revision: https://phabricator.services.mozilla.com/D164291
So entries now store the given timeout value (instead of clamping it to after "now").
And we store this timeout first, as it's accessed more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D164288
This ensures that 0-delay timers are executed very quickly; without this, they
would rely on the timer thread waking up "naturally" as scheduled, but on some
platforms there could be significant delays (many milliseconds) before the
thread would actually wake up, compared to notifications that are handled
almost immediately.
Even though by specs, timers may be subject to being late, some users of
0-delay timers, in particular through JS' `setTimeout(code, 0)`, rely on the
code being executed as soon as possible (i.e., queued pretty much immediately
on the event loop).
Until now, this was almost guaranteed by the very frequent calls to
RemoveTimer, which always notified the timer thread and made it wake up very
quickly.
However the following patch is going to remove notifications from RemoveTimer,
so before that one lands we now need to ensure that 0-delay timer will still
be invoked at least as quickly as before.
Depends on D146030
Differential Revision: https://phabricator.services.mozilla.com/D149706
Modify the code so that instead of getting microseconds by first
getting milliseconds, then multiplying by 1000, it retrieves the
microseconds value directly.
Differential Revision: https://phabricator.services.mozilla.com/D143472
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
`profiler_add_marker()` now checks if the marker's target thread is actively being profiled. This is to prevent adding markers that would be discarded anyway, from taking CPU time to process, and from using space in the profile buffer.
This means that `profiler_thread_is_being_profiled(ProfilerThreadId)` must be used when a marker is intended for another thread, i.e., when it uses the MarkerThreadId option.
(Note: since baseprofiler::profiler_thread_is_being_profiled(ProfilerThreadId) is not available, baseprofiler::AddMarker cannot prevent markers targetted at non-profiled thread; There are none yet anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D128576
These changes were necessary for me to build successfully with this in my
mozconfig:
ac_add_options --enable-debug
ac_add_options --disable-unified-build
ac_add_options --enable-profiling
While I'm here, I removed a duplicate include in InputTaskManager.h, and made
nsThreadPool.cpp include its own header first, to match Gecko common practice.
Differential Revision: https://phabricator.services.mozilla.com/D127503
Justin Link