Support low memory detection and mitigation in GeckoView
Categories
(GeckoView :: General, enhancement)
Tracking
(Not tracked)
People
(Reporter: nalexander, Unassigned)
References
Details
Fennec had a low memory detection and mitigation system: see MemoryMonitor.java and friends. This system fed OS-level information into Gecko. That seems generally useful for all GeckoView-consuming applications, and might be part of (or feed into) the engine-gecko components in android-components. But this system also dropped App-specific caches and even App-level storage, and that is a rather awkward fit for GeckoView.
So this ticket tracks thinking about this problem and deciding what interfaces GeckoView might expose to enable similar functionality in Fenix and other applications.
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 1•5 years ago
|
||
CC to :smaug, :gsvelto, :etoop, :vchin. NI to :sebastian and :snorp for their comment.
|
||
Comment 2•5 years ago
|
||
I'd say that most applications would benefit from having the Gecko-specific part enabled. That will do useful things like running the GC/CC and purging caches and it has been shown to help keep Fennec alive when memory was tight.
We don't strictly need to provide anything at the application level though: the application can implement ComponentCallbacks.onLowMemory() or ComponentCallbacks2.onTrimMemory() on its own if it needs to purge caches and the like.
That is unless we want to make it easier for whoever is embedding Gecko. There are some interactions that might be beneficial: for example if the application has multiple tabs it might want to unload some of them, and that would be best done before Gecko runs all its own internal memory-pressure listeners. I don't know if we can devise an API for this but it might be worth considering.
|
||
Comment 3•5 years ago
•
|
||
Yeah, so in Android Components we already have some components that can react to low memory situations and we let the app tell us when this is the case, e.g. see:
https://github.com/mozilla-mobile/reference-browser/blob/master/app/src/main/java/org/mozilla/reference/browser/BrowserApplication.kt#L41-L46
For "engine" implementations we already support that a "tab" can either have an engine session (e.g. GeckoSession) or an engine state (e.g. GeckoEngineSessionState) attached. When needed we will restore the state to get an actual session (e.g. when displaying a tab). For example when we restore the browser state from disk initially all tabs will only have their state attached and we will not create a session for them until needed.
We haven't implemented memory saving capabilities for the engine yet, but we were planning to do something like that: In a low memory situation get the latest state and attach it to the tab, then close and free the engine session (Gecko Session). Do this either for all tabs but the selected tab or use some "last recently used" heuristic.
|
||
Updated•5 years ago
|
Yeah, I think for the most part we can delegate low memory handling to the app as we appear to be doing today. We could expose methods in GeckoRuntime for doing the additional things that :gsvelto mentioned (GC/CC, purging caches). There's probably not a whole lot of value in going granular here -- I imagine GeckoRuntime.reduceMemoryUsage() is fine for the vast majority of use cases.
|
|
||
Comment 6•5 years ago
|
||
Ideally it's sufficient to expose NS_DispatchMemoryPressure(). It only needs to be called once in the main process for the message to be propagated to all listeners both in the main process and content processes. This might change in the future: if we find a better way to detect low memory scenarios we might want to let content processes call it directly but we're not there yet.
Description
•