"Last chance" GC on OOM?

[K. Moon]

Hi memory-dev,

I've been working on triaging crbug.com/1329340, and I think it's a result of GC-able memory not getting reclaimed often enough during layout on a very large document, and eventually crashing with an out-of-memory condition.

Coming from a Java background, I got to thinking about some of the GC ergonomics there, such as collecting based on mutator CPU utilization, allocation rate, fixed heap thresholds, etc. But then I remembered an even simpler, "last ditch" safeguard: trying to do a final garbage collection when memory is exhausted.

Does Oilpan + PartitionAlloc support anything like this already? I'm thinking attempts to allocate memory could block on a callback that triggers a full GC run, to attempt to free memory before finally crashing. Obviously, performance would not be good, and trying to do a GC while memory is exhausted sounds... exciting, but it possibly could prevent a number of OOMs which are due to not collecting often enough.

[Kentaro Hara]

@Michael Lippautz 

--
You received this message because you are subscribed to the Google Groups "memory-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memory-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-dev/CACwGi-5zy3jGgfBOPN2_KARoiVQ%3DyJ4AYzf8XboSKPgYK7MLfw%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Michael Lippautz]

On Thu, Jun 2, 2022 at 4:03 PM Kentaro Hara <har...@chromium.org> wrote:

@Michael Lippautz 

On Thu, Jun 2, 2022 at 10:59 PM K. Moon <km...@chromium.org> wrote:

Hi memory-dev,

I've been working on triaging crbug.com/1329340, and I think it's a result of GC-able memory not getting reclaimed often enough during layout on a very large document, and eventually crashing with an out-of-memory condition.

Coming from a Java background, I got to thinking about some of the GC ergonomics there, such as collecting based on mutator CPU utilization, allocation rate, fixed heap thresholds, etc. But then I remembered an even simpler, "last ditch" safeguard: trying to do a final garbage collection when memory is exhausted.

 

Does Oilpan + PartitionAlloc support anything like this already? I'm thinking attempts to allocate memory could block on a callback that triggers a full GC run, to attempt to free memory before finally crashing. Obviously, performance would not be good, and trying to do a GC while memory is exhausted sounds... exciting, but it possibly could prevent a number of OOMs which are due to not collecting often enough.

Oilpan already supports most of the scheduling techniques listed above.

It currently does not support a last resort GC when failing to commit memory. Can you file a bug on the V8 tracker using component Oilpan? V8 already implements these kinds of GCs and we can use a similar mechanism for Oilpan. We have this on our backlog but can prioritize if there's more demand.

While these GCs are generally useful to drag out OOMs, they are not a clear win. More often than not, when reaching the system limits for memory, the OOM will anyways happen and crashing earlier safes (possibly a lot of) CPU time.

 

-Michael

[K. Moon]

Thanks for considering it! Filed as crbug.com/v8/12934.