Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 20, 2020 7:02 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on January 20, 2020 4:30 am wrote:
> > 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.
>
> That's for a single content process in a 32-bit build; it's definitely possible if
> the user had only one tab allocated to it. Also since it was running out of memory
> the process had already been minimized multiple times (15 to be precise, see the LowCommitSpaceEvents
> entry in the metadata tag) which would have made it smaller too.
>
> Of course that user was not running Slack or its ilk in that tab.
>

32-bit build? Then, may be. I didn't use it for a few years.

[O.T.]
I'd like to use 32-bit FF, but on WinXP, which is not supported by Mozilla. So, I use K-Meleon here, which is pretty buggy, but far less resource hog then the last FF (52.0.2).
[O.T.]

> > 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.
>
> That's the PhysicalAvailable entry of the PERFORMANCE_INFO field obtained via GetPerformanceInfo().
> According to Microsoft documentation that's the amount of physical memory immediately available w/o
> writing to disk. That should translate to free physical memory plus all the clean pages in the filesystem
> cache. I'm not sure what the task manager uses but they're most likely not the same measurements.


Yes, that's more relevant than "Free" of task manager, probably the same as "Available" in there.
Still sounds a little pessimistic in context of allocation, but I don't know how to get a better number.

Still, two numbers together make no sense. The report has to be wrong.
Except, you said, it's 32-bit. There is a small chance that numbers are correct, but we have a case of helplessly fragmented process's *virtual* address space.