Closed Bug 1587853 Opened 5 years ago Closed 5 years ago

Support low memory detection and mitigation in GeckoView


(GeckoView :: General, enhancement)

Not set


(Not tracked)



(Reporter: nalexander, Unassigned)



Fennec had a low memory detection and mitigation system: see 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.

Component: Android Studio and Gradle Integration → General
Product: Firefox Build System → GeckoView

CC to :smaug, :gsvelto, :etoop, :vchin. NI to :sebastian and :snorp for their comment.

Flags: needinfo?(snorp)
Flags: needinfo?(s.kaspari)

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.

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:

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.

Flags: needinfo?(s.kaspari)
Closed: 5 years ago
Resolution: --- → DUPLICATE

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.

Flags: needinfo?(snorp)

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.

You need to log in before you can comment on or make changes to this bug.