Anon (anon.delete@this.anon.com) on January 15, 2020 3:43 am wrote:
> Sure, that's exactly the behavior some are advocating here, and that's what Windows API promise, if you commit
> 1TB of memory Windows will only return success if it can grantee you will have access to all that memory,
> and will fail if it can't, so apps may choose a less memory hungry algorithm, failing to commit 1TB doesn't
> means it can't commit 1GB, but why assume apps will commit memory that will never be touched?

Because in my experience they do all the time. My guess is that they don't do it directly, see below.

> WTF was committing 140GB of memory?

Your guess is as good as mine. Firefox wasn't because we track committed memory so it was either another application or some library outside of our control. We've seen graphics drivers committing truckloads of memory for example without using it. My guess is that they do so to make sure they can swap stuff in and out of VRAM. That's the biggest problem we face with OOM crashes on Windows, in over 2/3 of the cases the machine still has more than enough physical memory available but it went OOM because of the lack of commit-space.

I have investigated the problem extensively using our crash report data but haven't found a solution yet simply because it's not our code that's responsible for that behavior (or at least not directly).