>>38131800There is a fixed commit charge cap for each application based on the total memory of the device. This is typically 180MB. Any allocations within an app process that would cause the cap to be exceeded fail with E_OOM. The application *could* handle this gracefully, but no applications actually do and instead they just crash.
If an application requests memory that would leave it under the cap, but the OS does not have enough free memory to service the request, it will tombstone other applications until there is enough. This involves saving out the background apps navigation state to disk, and then purging/reclaiming the memory. Well written apps will be able to restore their state when "resumed" (navigated back to), by including important information like scroll positions and expansion states in their navigation state. This process is transparent to the user, and the apps are still visible in the OS backstack when tombstoned.
If the application is under cap and requests an allocation that the OS cannot service, and there are no apps in the backstack that can be tombstoned, the allocation will fail with E_OOM as above.
Allocations from OS processes will never fail as the OS is guaranteed to run well under the device total memory.