A last ditch GC shouldn't evict the nursery.
Categories
(Core :: JavaScript: GC, enhancement, P3)
Tracking
()
People
(Reporter: pbone, Unassigned)
References
(Blocks 2 open bugs)
Details
A last ditch GC shouldn't evict the nursery.
This sounds far-out, so I'll explain.
The problem we want to avoid is OOM while evicting the nursery, because it can cause more chunks to be allocated, but that may fail and then we crash like Bug 1472062.
So how about when we begin a last ditch GC we don't evict the nursery, but we do scan it (or trace it for better results) and use it as part of the root set for collecting the tenured heap.
I think the tricky thing may be whether we need to fix up any of our remembered sets so that if something was freed, or freed and re-allocated in the tenured heap that was stored in a remembered set then things still work correctly.
|
||
Comment 1•5 years ago
|
||
You would need to make the nursery iterable. You would also need to answer the question of how many OOMs this would fix -- about what percentage of last ditch nursery OOMs aren't going to just lead to a later OOM anyway. (pbone, I know you know this; you said it yourself in bug 1472062 comment 7.)
There's an even more interesting question: what percentage of the time do heroic efforts near OOM lead to a worse user experience than crashing the content process? But that's harder to answer, at least on Windows. (Elsewhere we could look at hard page faults.) gsvelto's bug 1472062 comment 28 suggests that at least the increase in OOMs we've been seeing is of this variety -- we get low on memory, start sending out memory pressure events, struggle for a while, then die an OOM death.
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Steve Fink [:sfink] [:s:] from comment #1)
You would need to make the nursery iterable.
Oh your're right. I forgot it wasn't iterable. You could do it by tracing, but is that a good idea?
You would also need to answer the question of how many OOMs this would fix -- about what percentage of last ditch nursery OOMs aren't going to just lead to a later OOM anyway. (pbone, I know you know this; you said it yourself in bug 1472062 comment 7.)
:-) Yeah, we keep going over this point. I think we lack the data to do that. But it's also a good reminder anyway.
By stopping OOMs here I might be shifting them to some other component. which is not great. However what I hope is that by not OOMing here we get into a state where we can't collect enough memory (or already did a last ditch collection) recently so it's better just to fail an allocation. Possibly rasing an out-of-memory exception that the JavaScript app has to deal with (is that something we can do?) And not shifthing that blame out of the JSGC component, but all the way right out of Firefox ;P
There's an even more interesting question: what percentage of the time do heroic efforts near OOM lead to a worse user experience than crashing the content process? But that's harder to answer, at least on Windows. (Elsewhere we could look at hard page faults.) gsvelto's bug 1472062 comment 28 suggests that at least the increase in OOMs we've been seeing is of this variety -- we get low on memory, start sending out memory pressure events, struggle for a while, then die an OOM death.
Yeah, I think that may depend on how far we push the OOM responsibility to.
|
||
Comment 3•3 years ago
|
||
This seems like it would add a complex special case that wouldn't get exercised often and might not actually improve things that much. I think we should looks at other ways of addressing the OOM problem.
Description
•