Automatically unload (discard/hibernate) longly unused tabs to free RAM (when running out of RAM)
Categories
(Firefox :: Tabbed Browser, enhancement, P3)
Tracking
()
People
(Reporter: robert_abc3, Unassigned)
References
(Blocks 3 open bugs)
Details
It should be possible to set Firefox to trigger tab discarding when only free physical memory is running low. User should have a choice to choose between 3 options for browser.tabs.unloadOnLowMemory:
(1) no tab discarding,
(2) tab discarding when the total amount of both free physical memory and swap space is running low (provided in Bug 675539),
(3) tab discarding when free physical memory is running low (default setting) (Bug 1553260).
Tab discarding when free physical memory is running low should be set as default.
Alternatively, values (2) or (3) should be chosen automatically by Firefox based on total RAM present in PC/device: (2) if less than 8 GB is available in PC, and (3) if 8 GB or more is available. This value could be slightly different for different operating systems; user could have option to change this value too.
Discussion:
https://www.reddit.com/r/firefox/comments/brafza/latest_firefox_release_is_faster_than_ever_the/eoc44sk
https://www.reddit.com/r/firefox/comments/bncank/firefox_beta_keeps_reloading_tabs_on_a_pc_with_16/enis26r/?context=5
|
||
Comment 1•5 years ago
|
||
Not sure about 8GB limit (maybe 4 or 6 should be Ok?) but I agree that (3) should be default at least for 1-3 GB RAM devices. My opinion is based on Firefox for Linux (bug 1532955) usage experience of HP Stream 7 Tablet (1 GB RAM), Lenovo Miix2 8 (2 GB RAM), DEXP Ursus 10XW (2 GB RAM), Dell Venue 8 Pro 5855 (2 GB RAM) and other similar tablets.
|
||
Comment 2•5 years ago
|
||
Option 3 could be hard to implement because of the page cache. A lot of physical memory is usually consumed by the page cache and we don't want to unload tabs if physical memory is low because of that, the OS will reclaim it so we don't need to do anything.
This is not a problem on Linux where /proc/meminfo offers MemAvailable field which is just that (free memory + memory used by the page cache) but I'm not sure on Windows or Mac. I should investigate those two platforms to ascertain if it's feasible.
That being said if it is the changes should be minimal as the available memory tracker already has provisions to respond to low-physical memory scenarios.
|
||
Updated•5 years ago
|
(In reply to Gabriele Svelto [:gsvelto] from comment #2)
Option 3 could be hard to implement because of the page cache. A lot of physical memory is usually consumed by the page cache and we don't want to unload tabs if physical memory is low because of that, the OS will reclaim it so we don't need to do anything.
This is not a problem on Linux where /proc/meminfo offers MemAvailable field which is just that (free memory + memory used by the page cache) but I'm not sure on Windows or Mac. I should investigate those two platforms to ascertain if it's feasible.
That being said if it is the changes should be minimal as the available memory tracker already has provisions to respond to low-physical memory scenarios.
The main idea here is to prevent Firefox from using swap file (especially if it is on HDD). I stated "free RAM", but I mean any RAM available for Firefox including free and RAM memory which can be easily made available for the browser, without the need to go to swap file.
|
|
||
Comment 4•5 years ago
|
||
(In reply to Robert Ab from comment #3)
The main idea here is to prevent Firefox from using swap file (especially if it is HDD). I stated "free RAM", but I mean any RAM available for Firefox including free and RAM memory which can be easily made available for the browser, without the need to go to swap file.
Indeed; heavy swapping rarely provides a good user experience so we want to avoid that.
|
|
||
Comment 5•5 years ago
|
||
Also swapping to eMMC shorten device lifespin as it usually soldered on the board (like on devices I mentioned above).
|
|
||
Comment 6•5 years ago
|
||
(In reply to russianneuromancer from comment #5)
Also swapping to eMMC shorten device lifespin as it usually soldered on the board (like on devices I mentioned above).
Good point.
I'd suggest to widen a bit the use case: for example, I am more interested in unloading tabs to stop them from using CPU than because of memory usage.
Do you know when this future will be implemented in Firefox?
|
|
||
Comment 9•5 years ago
|
||
We don't have a plan yet but it will be discussed this week.
|
Reporter | |
Comment 10•5 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #9)
We don't have a plan yet but it will be discussed this week.
Any news?
|
|
||
Comment 11•5 years ago
|
||
Automatic tab unloading has been disabled due to a bug in the low-memory detection logic, see bug 1558930 for more details. Until that's fixed we won't be able to turn it back on. Regarding unloading long inactive tabs we discussed implementing the Page Lifecycle API, possibly feeding back changes into the draft spec. Idle tab unloading will probably happen within that context.
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 12•5 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #11)
Automatic tab unloading has been disabled due to a bug in the low-memory detection logic, see bug 1558930 for more details. Until that's fixed we won't be able to turn it back on. Regarding unloading long inactive tabs we discussed implementing the Page Lifecycle API, possibly feeding back changes into the draft spec. Idle tab unloading will probably happen within that context.
There are 2 similar bugs: Bug 675539 (with Bug 1558554 as follow-up), and Bug 1553260? Are you talking about Bug 1553260?
|
|
||
Comment 13•5 years ago
|
||
I was talking about bug 675539, bug 1553260 was not implemented yet.
|
|
Reporter | |
Comment 14•5 years ago
•
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #11)
(...) Regarding unloading long inactive tabs we discussed implementing the Page Lifecycle API, possibly feeding back changes into the draft spec. Idle tab unloading will probably happen within that context.
It will be useful also for this API to give options to add-ons to be able to discard tabs after given time. Chrome extensions, like The Great Suspender, can perform these actions already. (See also The Great Discarder).
|
|
||
Comment 15•5 years ago
|
||
Add-ons can already do that, there's a few available on Firefox too.
| Comment hidden (obsolete) |
|
|
Reporter | |
Comment 17•5 years ago
|
||
Do you have plans to implement this bug?
|
|
||
Comment 18•5 years ago
|
||
Yes, it's something we have discussed internally. We need more data and we need basic tab-unloading-on-low-memory to be working first. In the meantime interested users can experiment with the Reduce RAM Usage add-on which is a simple time-based tab unloader.
|
||
Comment 19•5 years ago
|
||
Should block bug 565512
|
||
Comment 20•4 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #18)
In the meantime interested users can experiment with the Reduce RAM Usage add-on which is a simple time-based tab unloader.
that addon is not available anymore.
|
||
Comment 21•4 years ago
|
||
(In reply to Tortino from comment #20)
that addon is not available anymore.
There is also Auto Tab Discard (Github), which does the same thing.
|
||
Updated•2 years ago
|
Description
•