Mozilla cut Firefox's Windows out-of-memory crashes by over 70% with wait-and-retry

On Windows, running out of memory was Firefox's biggest source of crashes — yet many affected users had gigabytes of physical RAM free. Windows caps how much memory an application can commit at RAM plus swap-file size, and Firefox could not control everything that consumed that 'commit space': graphics drivers commit memory for textures that is rarely used but still counts against the limit. Firefox had spent years trimming its own memory use and monitoring regressions, and none of those efforts moved the crash rate the way the eventual trick did.

The conventional response to an allocation that cannot be satisfied is to give up: most failure paths have no sensible way to continue, so the browser crashed in a controlled way. That treated the commit-space ceiling as fixed, when on Windows it is not — the operating system automatically enlarges the swap file when it is nearly full, expanding the amount of memory applications can commit.

Mozilla's move was to make the main process wait briefly when an allocation failed and then retry it, giving Windows time to grow the page file. The stall also buys something else: Firefox runs as several processes and can survive losing any of them except the main one, so during the delay a content or GPU process with runaway memory tends to die first, freeing room for the browser to resume. Losing a web page or seeing a brief flash beats a full browser crash.

The trick shipped in Firefox 105 and cut out-of-memory browser crashes per active usage hour by more than 70% — far beyond Mozilla's rosiest predictions. The team had used the same approach successfully on Firefox for Android and Firefox OS, and a small rise in tab crashes under memory pressure was the next thing they set out to reduce.

A failed allocation need not be fatal on Windows — the OS grows the page file on demand, so waiting and retrying turns an out-of-memory crash into a brief stall.

Windows does not kill an application whose allocation fails — the call returns an error, so the process can choose to wait and try again instead of dying.

The commit-space ceiling is expandable: Windows auto-grows the swap file when nearly full, and a short pause gives it time to do so.

Firefox's multi-process design means stalling the main process lets a reloadable content or GPU process die first and free memory, protecting the whole browser.

The change altered failure handling rather than memory usage, which is why one small fix outperformed years of footprint trimming.

When a platform can expand a resource on demand, pause instead of crashing on failure — and in a multi-process app let a reloadable subprocess absorb the damage first.

Firefox 105 shipped the wait-and-retry behaviour in September 2022, and telemetry showed out-of-memory browser crashes per active usage hour fell by more than 70% — 'far more than our rosiest predictions.' The stall caused a smaller rise in tab crashes, which the team then worked to cut, and Mozilla began distinguishing low commit-space from low physical memory so Firefox could respond differently and reduce swapping. Engineer Raymond Kraesig implemented the trick and monitored its impact; the same technique had already worked on Firefox for Android and Firefox OS.