1782178 - Split low-memory detection between low physical memory and low commit-space using different mechanisms

Status: NEW

(Core :: Memory Allocator, task)

Description

[Gabriele Svelto [:gsvelto]]

The current code in the AvailableMemoryTracker/AvailableMemoryWatcher evolved from the old tracker in the hope that we could better detect low-memory condition and unload tabs directly upon hitting them. However we still use a mixed system to detect these conditions, first using Windows' memory resource notifications then polling with GlobalMemoryStatusEx().

The main issue with this system is that memory resources check for low physical memory while what the watcher tries to detect is low commit space. The reason for this mismatch is that outside of memory resources we didn't have a non-polling mechanism and for power-consumption reasons we wanted to move away from polling. We want to remove this mismatch for two reasons:

• While we used this detection to drive tab unloading it only partially worked, unloading a tab requires memory for shutdown so it lead to more OOM crashes in child processes, as the unloaded process tried to shut down cleanly (main process crash rate also went down, which is something we want to retain)
• Because low commit-space detection relies on low physical memory we would miss scenarios where we'd be low on commit-space but not on physical memory

Bug 1716727 gives us a new non-polling signal to detect when we're low on commit-space: if an allocation failed and we recovered from that condition. So I propose the following:

• Use memory resources to detect low physical memory and unload tabs in response to this signal (low physical memory means the user performance is degraded by swapping and unloading a tab is going to help, this would also be useful to kill background tabs that might have been leaking memory)
• Use low commit-space detection to drive memory-pressure events - these are guarantee to reduce our memory footprint without requiring a memory usage spike in the meantime