Open Bug 669120 Opened 13 years ago Updated 2 years ago

Fire heap-minimize notification when FF is minimized (or unfocused?)

Categories

(Core :: General, defect)

defect

Tracking

()

People

(Reporter: justin.lebar+bug, Unassigned)

Details

(Keywords: memory-footprint, Whiteboard: [MemShrink:P2])

I'm beginning to think that we should fire a heap-minimize notification when the browser is minimized, and possibly when the browser loses focus (potentially on a timeout -- fire heap-minimize if the browser is minimized or unfocused for more than X seconds).

We can watch RSS / available memory (as in bug 664291) and minimize our usage only when we believe that memory is tight.  But even if we did a perfect job and always fired a memory-pressure notification when the system was running low on memory, we could still end up holding onto memory when the user isn't actively using FF, if the system isn't out of RAM.

Giving back memory even when we're not actively running low is good for a number of reasons:

 * The system gets memory back immediately, instead of after it needs it.  If we wait until memory is low to give up our memory, we may be too late.

 * The OS can use the extra memory we give back for buffer caches, potentially speeding up the user's machine.

 * A user checking task manager sees that we're using less memory than she would otherwise, and doesn't tell all her friends not to use FF because it's a hog.  (This is not entirely a joke.)

memory-pressure currently triggers a gc/cc, clears bfcache, and drops all decoded images in inactive tabs, among other things.
Keywords: footprint
Whiteboard: [MemShrink]
For what it's worth, I believe back in the day we used to do this on Windows (in particular, told the OS to minimize our heap).

That made the OS aggressively swap us out to disk, so restoring from minimized state took a lot longer (order of tens of seconds) than just restarting the browser.

You may want to look up some of those old bug reports so we can avoid repeating the same mistakes....

Now just firing memory-pressure might be ok, as long as we stay away from the OS-level heap-minimize stuff.
I also wonder if we should have two levels of heap-minimization notifications, and we could fire a weaker one when FF is minimized, and a stronger one when we're close to OOM or paging or whatever.
What would one get rid of on the stronger memory-pressure notification that we wouldn't get rid of on the weaker one?

I guess we could unload some tabs when memory is really tight, although I'm not sure we want to go there.
OS: Linux → All
Hardware: x86_64 → All
(In reply to comment #1)
> Now just firing memory-pressure might be ok, as long as we stay away from
> the OS-level heap-minimize stuff.

Yeah, I don't think we want to give the OS an excuse to swap us out more than it otherwise would.

I could imagine madvising areas of memory we think are less-important if we notice we're already being swapped out, but that's probably more trouble than it's worth.
Doing a GC/CC while the user is not using the browser has the nice property that pause times are irrelevant.
I think a fair middle ground is to just do a GC/CC and not drop anything like the image cache/BF cache/etc.
Whiteboard: [MemShrink] → [MemShrink:P2]
Just to throw out one option: I bet if we cleared bfcache for everything except the current tab, few people would notice.

I think before we can decide whether we want to throw away bfcache, we should figure out how much memory it actually accounts for.
> I think before we can decide whether we want to throw away bfcache, we
> should figure out how much memory it actually accounts for.

Per-tab memory reporting (bug 687724) will tell us that.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.