1703839 - Failing to map shared surfaces should OOM abort as late as possible

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Andrew Osmond [:aosmond] (he/him)]

Bug 1702132 suggests that it may take time in some cases for unmapping of surfaces to occur. We don't really need to OOM abort in general if we fail to map a surface when we initially receive it (unless it is a configuration that doesn't support unmapping). Instead we can defer this to when the frame is rendered to give the OS a chance to process the unmaps. We suspect this is the case because we see a difference between the available virtual memory when we fail to map and then abort, and when the crash report is actually processed (both using GlobalMemoryStatusEx).

Comment 1

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1703839 - Defer OOM crashing for mapping in shared surfaces to frame rendering.

If we fail to map in a shared surface that we support unmapping for,
don't OOM crash immediately if this is the first time we are mapping it.
This is because we probably freed up a bunch of virtual memory already
purging the expiration tracker, but on Windows, this may take some time
before the virtual address space is available for reuse. Since there
will be some time gap between the mapping and the frame rendering, this
may be sufficient time to recover in some cases, avoiding a GPU process
OOM crash.

This should only affect 32-bit users, since we never unmap on 64-bit
builds.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/48a4a6a4340f
Defer OOM crashing for mapping in shared surfaces to frame rendering. r=jrmuizel

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/48a4a6a4340f