942892 - Warn users when their Firefox appears low on VM before crashing

Status: NEW

(Firefox :: General, defect)

Description

[Benjamin Smedberg]

Users who are running out of VM space will see their contiguous VM size go down as they approach OOM. We should warn users before they hit actual OOM, so that they can save work and restart Firefox.

This is Windows-only for now, since that's where we have the data. nsIMemoryReporter.vsizeMaxContiguous is the datapoint we need to monitor. It was added in bug 939385.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Do we need to preallocate memory for this warning? Otherwise this warning could push us to OOM :)

Comment 2

[Justin Dolske [:Dolske]]

Is there data to help us pick a good threshold? (eg once vsizeMaxContiguous reaches some X, how likely is it a crash will occur?) Seems like we wouldn't want this too low (false alarms), nor too high (too late to do anything).

Do we know anything about the rate at which vsizeMaxContiguous tends to change as it approaches exhaustion? Is it a slow decrease over a long time, or does it happen rapidly? Both?

Comment 3

[Benjamin Smedberg]

We don't need to preallocate memory. Simple dialog boxes don't cost much memory in general.

What we're mainly worried about is small/normal heap allocations failing data shows that normal small allocation start failing when there is 1-10MB of vsize-max-contiguous left. Since that is a very small fraction of the minimum 2G address space, I'd propose a cutoff of 25MB vsize-max-contiguous, which is about 1% address space remaining, and should be enough for jemalloc to keep working for a bit. We're unlikely to be able to recover after that point anyway.