Bug 1505622 - Skip last ditch GC and fail the allocation if we already did last ditch GC within the last minute
47 bytes, text/x-phabricator-request
|Details | Review|
In the DOM when we get a memory pressure event we attempt a last ditch GC, and then if the pressure is ongoing we don't do it again. The reasoning is if the user is low on memory we'd only lag/jank Firefox/their system and probably end up crashing anyway. On the SpiderMonkey side this is not the case, but probably should be :bz has a Firefox process stuck in a loop attempting last ditch GCs 10:30 < bz_away> One is via the array allocation 10:30 < bz_away> Which does JSObject* js::gc::GCRuntime::tryNewTenuredThing<JSObject, (js::AllowGC)1>(JSContext*, js::gc::AllocKind, unsigned long) 10:30 < bz_away> Which does the GCRuntime::collect() call and 10:47 < bz> pbone: In particular just the nsObserverService::NotifyObservers garbage-collection-statistics bit We should probably avoid two last ditch GCs in a row (and also within a certain time window). It may be a better user experience just to fail the allocation and let the calling JS (in this case browser chrome) deal with it. In this case bz's allocation sites seem to be in browser chrome JS, but the memory leak could be elsewhere.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/0199e2beb6f9 Skip last ditch GC and fail the allocation if we already did last ditch GC within the last minute r=sfink
Flags: needinfo?(jcoppeard) → needinfo?(sphink)
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c6317f06ed07 Skip last ditch GC and fail the allocation if we already did last ditch GC within the last minute r=sfink
You need to log in before you can comment on or make changes to this bug.