Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 19, 2020 11:55 pm wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 18, 2020 2:15 pm wrote:
> > Fine. I hereby formally submit FireFox as an example of a piece of software that doesn't handle all
> > allocation failures gracefully. My evidence includes hundreds of pages of crash reports despite developers
> > putting an overwhelming amount of effort into failing to solve problems that were caused by:
> >
> > a) overcommit masking symptoms of idiotic "continually increasing
> > without limit resource consumption" design decisions
> >
> > b) overcommit creating an attitude of "can't justify the hassle of dealing with allocation
> > failures' in some developers, leading to parts of the software being shit (e.g. not
> > passing failure up the call chain to a point where the user can be informed "Sorry,
> > not enough memory to do that" without screwing everything else up/crashing).
>
> Alright, now I see your point: I'm holding it wrong.
>
> > It's entirely possible, you just refuse to try.
> >
> > Lets's look at a piece of "my" evidence (the first crash log in the list): https://crash-stats.mozilla.com/report/index/ed62286b-ccd3-4d3f-b8d3-5d4a00200108
> >
> > The bottom of the page shows about 20 places that could have caught a "std::bad_alloc";
> > where you are able to choose any of those ~20 places (wherever is most convenient)
> > to handle the allocation failure instead of crashing.
>
> See the name of the class at the top of the stack? It's called AutoEnterOOMUnsafeRegion because it's
> used by the GC to handle parts of its run where it can't recover from an OOM - it usually can but
> it's not always possible. A compacting generational GC sometimes need to allocate memory to be able
> to make forward progress and the heap is in such a state that a failure is not recoverable.
>
> Also, funky datapoint: there's a memory report attached to that crash report and it indicates
> that the resident set is 88,61MiB. Does that fit your definition of a resource hog? It's
> also a perfect example of the limitations of Windows: with 271 MiB free physical memory
> it cannot satisfy a 256 bytes allocation for a process that's using 88 MiB.
>

Frankly, I can't imaging anybody using FF for a 10+ minutes with "resident set" (assuming that it means the same as Working Set (Memory) in Windows7 task manager) smaller than 100 MB.

Sound like near 100% chance of wrong number in crash report.
And quite likely "free physical memory" is wrong too, but if it's supposed to be the same as "Physical Memory - Free" in 'Performance' tab of Win7 task manager then this number is not particularly relevant anyway, because when system works as intended, majority of physical memory is used by File system cache, i.e. not Free, but available on demand.