Memory resource notification stops when the physical memory is low but the commit space is not low
Categories
(Firefox :: Tabbed Browser, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: toshi, Assigned: toshi)
References
Details
Attachments
(1 file)
There was a mistake in the Part4 patch of bug 1701368. If the memory resource callback is invoked and the commit space is low, it unregisters the wait handle without starting a timer. As a result, nsAvailableMemoryWatcher
stops watching the memory situation. We need to start a timer or re-register the wait handle in such a case to continue watching.
Assignee | ||
Comment 1•3 years ago
|
||
When the physical memory is low, Windows OS triggers the memory notification callback,
but we don't take any action if the commit space is not low because it is not the case
of a potential OOM crash. The problem is in that case, we unregister the wait handle
and exit from the callback. This means we lose a way to watch memory after that.
The proposed fix is to start a timer before exiting the callback. We could re-register
the callback, but it could be triggered too quickly if the low-physical-but-high-commit-space
situation lasts long. After the timer starts, the first timer handler (interval: 10 sec)
checks the commit space again, and if the commit space is still not low at that time,
we re-register the callback and stop the timer.
One tricky situation we need to consider is we don't actually start the timer while
the user is inactive. In that case, we mark the flag mNeedToRestartTimerOnUserInteracting
and start the timer when the user becomes active later. With that, OnHighMemory
can
be executed even when we didn't in the low-memory situation. So we need to check another
flag mUnderMemoryPressure
and record the telemetry and send a memory-pressure-stop event
only when we were in the low-memory situation.
Depends on D120021
Comment 3•3 years ago
|
||
bugherder |
Description
•