1308118 - Implement a floating threshold to send low memory notifications on Windows

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Gabriele Svelto [:gsvelto]]

+++ This bug was initially created as a clone of Bug #1301667 +++

I've tried to increase the low-memory threshold on Windows 32-bit builds since we almost never hit it, crashing because of an OOM condition instead. This had the unpleasant side-effect of slowing down Firefox to a crawl if the amount of free virtual memory hovered around the threshold (see bug 1306128 and bug 1307018).

One way to solve this kind problem we've deployed successfully in the past is to implement a floating threshold with exponential back-off (see bug 1234176 for an example of this).

The idea is to have two thresholds: a higher one and a lower one. The higher one represents soft memory pressure; when we hit we send a memory pressure event and then adjust the available memory tracker to not send any more events unless the lower trigger is hit (hard memory pressure).

At the same time we set up a timer that will check at a later time if enough memory was freed. If it was the time will bump up the threshold again. If it wasn't it will set a new timer and try again at a later time. Since enough memory might just not be available for a prolonged period of time this timer will have an exponential back-off mechanism to reduce the number of times it fires while failing to adjust the threshold.

Comment 1

[Gabriele Svelto [:gsvelto]]

Bug 1308403 made me realize another thing which might have made the issues in bug 1306128 and bug 1307018 really bad: on B2G after entering a memory pressure state we wouldn't keep sending memory pressure events again if the pressure didn't relieve (i.e. "low-memory" payload), we sent ongoing memory pressure events ("low-memory-ongoing") which didn't trigger additional GCs.

In addition to this bug 1308403 shows that having an additional event to communicate when memory pressure has subsided is useful; so I'll make sure to add both.

Comment 2

[Gabriele Svelto [:gsvelto]]

I've analyzed the code a little bit more and I've spotted another very problematic issue: when we're low on virtual memory we *always* send a memory pressure event even though we might just have sent another one before. This is going to be very, very painful, since memory pressure events might literally pile up in the event queue.

Comment 3

[Gabriele Svelto [:gsvelto]]

This is going to be trickier than I had anticipated because the callback in which we check the amount of available memory can be called on any thread and we can't use a lock inside of it so touching globals is a no-no.

Comment 4

[Gabriele Svelto [:gsvelto]]

Unassigning myself since I'm not currently working on this.

Comment 5

[Gabriele Svelto [:gsvelto]]

Closing this as INVALD since we'll probably move low-memory detection to use Windows memory resource notifications and that doesn't require an explicit threshold.