This is just a refactoring to have less copy&pasted code instead of more once we enable more targets for shutdown tasks.
Differential Revision: https://phabricator.services.mozilla.com/D258804
This improves the setup so that whenever there are only idle/deferred tasks, we can run low priority tasks immediately.
Manual testing shows that this way we get couple of more ticks every now and then.
Without this patch we'd rely on normal priority tasks, but since there might be multiple of those pending, ShouldGiveNonVsyncTasksMoreTime() would
return true.
So, low priority tasks are effectively "run when the queue is otherwise empty (but idle-type of tasks are still special)".
Differential Revision: https://phabricator.services.mozilla.com/D159583
`High` priority is being used for vsync tasks, so we should rename it to
make it clear, and renaming it also makes our priority naming less
confusing.
Differential Revision: https://phabricator.services.mozilla.com/D109536
`High` priority is being used for vsync tasks, so we should rename it to
make it clear, and renaming it also makes our priority naming less
confusing.
Differential Revision: https://phabricator.services.mozilla.com/D109536
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
CondVar already calls `AUTO_PROFILER_THREAD_SLEEP`, which shouldn't be called recursively.
mozilla::Monitor also uses CondVar, so it shouldn't be surrounded by `AUTO_PROFILER_THREAD_SLEEP` either.
Depends on D72850
Differential Revision: https://phabricator.services.mozilla.com/D72851
The basic idea, suggested by Olli, is that we can try to get a runnable in
ThreadEventQueue::GetEvent, and if that does not produce anything unlock our
mutex, do whatever idle state updates we need to do, re-lock our mutex. Then
always we need to try getting a runnable again, because a non-idle runnable
might have gotten queued while we had the lock unlocked. So we can't sleep on
our mutex, in the mayWait case, unless we try to get a runnable again first.
My notes on the current (pre this patch) unlocking setup follow.
------------------------------------------------------------
There are four places where we currently unlock:
1) IdlePeriodState::GetIdleDeadlineInternal. Needed only when !aIsPeek, to
RequestIdleToken, which can do IPC. The only caller, via
GetDeadlineForIdleTask, is PrioritizedEventQueue::GetEvent and only when we
selected the idle or deferred queue. We need this to set the proper deadline
on the idle event. In the cases when this unlock happens we currently _never_
return an idle event, because if we got here that means that we do not have an
idle token.
2) IdlePeriodState::GetLocalIdleDeadline. Needs to unlock to get the idle
period hint. The can get called from GetIdleDeadlineInternal in _both_ cases:
peek and get. The callstack for the get case is covered above. The peek case
is called from PrioritizedEventQueue::HasReadyEvent which is called from
ThreadEventQueue::HasPendingEvent.
3) IdlePeriodState::SetPaused, because it sends an IPC message. This is only
called from EnsureIsPaused, which is called from:
- IdlePeriodState::GetIdleDeadlineInternal. Only in the !aIsPeek case.
- IdlePeriodState::RanOutOfTasks called from:
- PrioritizedEventQueue::GetEvent if we fell into the idle case and our
queues are empty.
- PrioritizedEventQueue::DidRunEvent if we are empty.
4) IdlePeriodState::ClearIdleToken because it sends an IPC message. This is
called from:
- IdlePeriodState::RanOutOfTasks; see SetPaused.
- IdlePeriodState::GetIdleDeadlineInternal like EnsureIsPaused.
- IdlePeriodState::GetIdleToken if token is in the past. This is only
called from GetIdleDeadlineInternal, both cases.
- IdlePeriodState::FlagNotIdle called from PrioritizedEventQueue::GetEvent
if we find an event in a non-idle queue.
Or rewriting in terms of API entrypoints on IdlePeriodState that might need to
unlock:
* Anything to do with getting deadlines, whether we are peeking or getting.
Basically, if we need an updated deadline we need to unlock.
* When we have detected we are completely out of tasks (idle or not) to run.
Right now we do that when either we're asked for an event and don't have one
or if we run an event and are empty after that (before unlocking!). But the
unlocking or not happens in nsThreadEventQueue::DidRunEvent, so separately
from the getting of the event. In particular, we are unlocked before we
enter DidRunEvent, and unlock again before we return from it, so we can do
whatever updates we want there.
* When we have detected that we have a non-idle event to run; this calls
FlagNotIdle.
Differential Revision: https://phabricator.services.mozilla.com/D53631
This lets us determine the time that an event has been running, and the time
that the event spent queued - which can be used to figure out 'jank' at the
time the event was queued. For PrioritizedEventQueues, only if such queuing
would delay an input event then the queuing delay is reported.
Differential Revision: https://phabricator.services.mozilla.com/D41279
This lets us determine the time that an event has been running, and the time
that the event spent queued - which can be used to figure out 'jank' at the
time the event was queued. For PrioritizedEventQueues, only if such queuing
would delay an input event then the queuing delay is reported.
Differential Revision: https://phabricator.services.mozilla.com/D41279
Daniel Holbert