Reacting more strongly to low-memory situations in Firefox 25

Bas Schouten bschouten at mozilla.com
Tue Nov 26 01:15:44 UTC 2013





----- Original Message -----
> From: "Benjamin Smedberg" <benjamin at smedbergs.us>
> To: dev-platform at lists.mozilla.org, "Bas Schouten" <bschouten at mozilla.com>, "David Major" <dmajor at mozilla.com>,
> "Nathan Froyd" <froydnj at mozilla.com>, "Firefox Dev" <firefox-dev at mozilla.org>
> Sent: Monday, November 25, 2013 5:02:50 PM
> Subject: Reacting more strongly to low-memory situations in Firefox 25
> 
> 
> Unfortunately, often when we are out of memory crash reports come back
> as empty minidumps (because the crash reporter has to allocation memory
> and/or VM space to create minidumps). We believe that most of the
> empty-minidump crashes present on crash-stats are in fact also
> out-of-memory crashes.
> 
> I've been creating reports about OOM crashes using crash-stats and found
> some startling data:
> Looking just at the Windows crashes from last Friday (22-Nov):
> * probably not OOM: 91565
> * probably OOM: 57841
> * unknown (not enough data because they are running an old version of
> Windows that doesn't report VM information in crash reports): 150874
> 
> The criterion for "probably OOM" are:
> * Has an OOMAnnotationSize marking meaning jemalloc aborted an
> infallible allocator
> * Has "ABORT: OOM" in the app notes meaning XPCOM aborted in infallible
> string/hashtable/array code
> * Has <50MB of contiguous free VM space
> 
> This data seems to indicate that almost 40% of our Firefox crashes are
> due to OOM conditions.
> 
> Because one of the long-term possibilities discussed for solving this
> issue is releasing a 64-bit version of Firefox, I additionally broke
> down the "OOM" crashes into users running a 32-bit version of Windows
> and users running a 64-bit version of Windows:
> 
> OOM,win64,15744
> OOM,win32,42097
> 
> I did this by checking the "TotalVirtualMemory" annotation in the crash
> report: if it reports 4G of TotalVirtualMemory, then the user has a
> 64-bit Windows, and if it reports either 2G or 3G, the user is running a
> 32-bit Windows. So I do not expect that doing Firefox for win64 will
> help users who are already experiencing memory issues, although it may
> well help new users and users who are running memory-intensive
> applications such as games.

I'm a little confused, when I force OOM my firefox build on 64-bit windows it -definitely- goes down before it reaches more than 3GB of working set. Am I missing something here?

> 
> Scripts for this analysis at
> https://github.com/mozilla/jydoop/blob/master/scripts/oom-classifier.py
> if you want to see what it's doing.
> 
> = Next Steps =
> 
> As far as I can tell, there are several basic problems that we should be
> tackling. For now, I'm going to brainstorm some ideas and hope that
> people will react or take of these items.
> 

...

> 
> == Graphics Solutions ==
> 
> The issues reported in bug 930797 at least appear to be related to HTML5
> <video> rendering. The STR aren't precise, but it seems that we should
> try and understand and fix the issue reported by that user. Disabling
> hardware acceleration does not appear to help.
> 
> Bas has a bunch of information in bug 859955 about degenerate behavior
> of graphics drivers: they often map textures into the Firefox process,
> and sometimes cache the latest N textures (N=200 in one test) no matter
> what the texture size is. I have a feeling that we need to do something
> here, but it's not clear what. Perhaps it's driver-specific workarounds,
> or blacklisting old driver versions, or working with driver vendors to
> have better behavior.

I should highlight something here, caching the last N textures is only occurring in drivers which do -not- map into your address space as far as I have see in my testing. Intel stock drivers seem to map into your address space, but do -not- seem to do any caching. The most likely cause of the OOM here is simply that currently, we keep both the texture, and a RAM copy around of any image in our image cache that has been drawn. This means for users using Direct2D with these drivers an image will use twice as much address space as for users using software rendering. We should probably alter imagelib to discard the RAM copy when having hardware acceleration, and in that case actual address space usage should be the same for users with, and without hardware acceleration.

For what it's worth, just to add some info to this, in my own experience on my machines in most cases Firefox seems to climb to about 1.1-1.3 GB of memory usage fairly quickly (i.e. < 2 days of keeping it open), and sort of stabilize around that number. Usually when I do an about memory in this case my memory reports about 500 MB+ in JS, a surprising amount (150 MB) in VRAM usage for DrawTargets (this would be in our address space on the affected intel machines), we should investigate the latter. This is usually with about 20 tabs open.

Bas



More information about the firefox-dev mailing list