----- Original Message -----
> From: "Benjamin Smedberg" <benja...@smedbergs.us>
> To: dev-platform@lists.mozilla.org, "Bas Schouten" <bschou...@mozilla.com>,
> "David Major" <dma...@mozilla.com>,
> "Nathan Froyd" <froy...@mozilla.com>, "Firefox Dev" <firefox-...@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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
