Crashes are the most common cause of instability that users encounter when using Firefox on the Windows platform, and this phenomenon is far more severe on the Windows platform than on Linux and macOS. As a result, Mozilla has devoted significant resources to reducing Firefox’s memory consumption, and carefully monitors these changes. However, Mozilla recently revealed that all their previous efforts were not as effective as the one small change they implemented in Firefox 105.

First, to understand why applications running on Windows are more likely to run out of memory and crash than other operating systems, it’s important to understand how Windows handles memory.

All modern operating systems allow applications to allocate an address space. Initially, these blocks simply represent address ranges that are not backed by physical memory when no data is stored in them. When an application starts using its reserved address space, the OS will take out a chunk of physical memory to back it, possibly swapping out some existing data if necessary. Both Linux and macOS work this way, as does Windows, it just requires an extra step compared to other operating systems.

After an application has requested a block of address space, the application needs to commit the range for use before it can use it. This range requires Windows to ensure that it can always find physical memory to back it. After that, Windows behaves like Linux and macOS indistinguishable. Therefore, Windows limits the amount of memory that can be committed, which is the sum of the machine’s physical memory plus the size of the swap file.

The commit space is a hard limit that the application faces, and as soon as this limit is reached, the memory allocation will fail. When Firefox developers analyzed browser crashes, they found that in many cases when the crash occurred, there was still a lot of available physical memory on the user’s device, but the commit space was exhausted.

So they decided to use some tricks to avoid this problem, that is, when the memory allocation fails, the browser does not crash immediately, but waits first, and then tries to re-allocate the memory. While this can cause the browser to freeze for a brief fraction of a second, it’s far better than a complete crash (when the swap file is nearly full, Windows will automatically resize it, increasing the commit space available).

Mozilla implemented this change in Firefox 105, which significantly improves the stability of the browser. The graph below shows how many out-of-memory browser crashes users experienced per hour of active use (crashes were reduced by more than 70%, far exceeding what Mozilla originally predicted).

Mozilla said that although they have implemented this improvement in Firefox 105, in fact this improvement has not been fully completed, because currently slowing down the main process will cause a small increase in the number of tab crashes, which is also unpleasant for users. Experience, while not as annoying as a full browser crash, the team is still trying to reduce this from happening.