The first computer I owned shipped with 128 KiB of RAM and to this day I’m still jarred by the idea that applications can run out of memory given that even 15-year-old machines often shipped with 4 GiB of memory. And yet it’s one of the most common causes of instability experienced by users and in the case of Firefox the biggest source of crashes on Windows.
A detailed technical explanation of why Windows’s memory management – and only Windows’s – is causing so many crashes for Firefox, as well as a solution they found to address the problem.
Nice article, mostly because they explain what the problem was. The solution was quite generic (spoiler alert: retries).
And it’s always fun to see how small improvements can have a bit impact in stability or performance.
I suspect the problem was Firefox has bugs (e.g. maybe asks GPU driver to allocate memory for textures and then never asks GPU driver to free the textures later) and instead of finding the real problem and solving it they just slapped an incompetent hack over the symptoms; so that instead of continual memory leaks because of their bugs (and earlier crashes when there’s no more “currently committable” memory ) you get continually growing swap file because of their bugs (and later crashes, when there’s no more free disk space).
That’s not what’s happening, unless you think Chrome has it even worse. What’s likely happening is that the graphics driver is committing chunks of memory to be able to swap textures out of GPU ram, but never ends up using them hence why they’re not backed by physical memory. If Firefox were leaking textures we wouldn’t see unaccounted commit space, we’d see unaccounted physical memory as it’s all tracked within Firefox (just browse to about:memory to get an idea of how it’s done).
That being said if you don’t believe me try opening both an instance of Firefox and one of Chrome, browsing to the same site then comparing physical memory use and commit space use for both. Spoiler: Chrome usually uses more physical memory than Firefox and a *lot* more unused commit space.
It’d have to be pretty close to what’s happening.
Firefox has been tracking stats for ages while trying to find/fix their memory leaks, so they can do “triage” – e.g. determine if all the computers that crash happen to have something in common – the same amount of memory, a low amount of free disk space, the same video driver, a video driver from the same company, or…
So… how plausible is it that every video driver from every manufacturer (NVidia, AMD, Intel) has exactly the same bug that only effects Firefox and nothing else?
It’s not a bug, it’s a requirement. Drivers need to be able to swap out textures to system RAM when the total size of the textures exceeds the RAM available to the GPU. To do so they commit buffers the same size of textures which they will use only when needed, hence the apparent waste.
Um? Are you saying that Firefox is required to not to tell GPU when it no longer needs resources (that GPU allocated on Firefox’s behalf previously)?
This is easy, disable the update service and install chrome.
After years of running Firefox ESR in Windows 10, I have yet to experiment a crash.
How much RAM do you have and how big is your swap file? This is talking about how Windows’s lack of overcommit makes OOM crashes more likely on machines with limited RAM because GPU drivers reserve RAM they often wind up never using.