Created attachment 729919 [details]
Test procedure and results
This bug is related to issues found and discussed in Bug 852520, and is related to releasing of memory that has been GCed in Firefox to the system on Mac OS X.
In Bug 852520 it was found that memory GCed in Firefox isn't necessarily released to the system right away, and will only be released if the system is running out of memory. In order to observe the effectiveness of the intended automatic method of releasing memory, I set up a test scenario where an instance of Firefox had a large amount of memory freed from GC, yet was still not released to the the system. I then ran another app (also Firefox) on the system to use up available memory so I could monitor if and how well the memory freed from Firefox was being made available to the system.
I observed that the manner in which memory was released was less than optimal, in that the system began transferring memory to swap, while there was still significant amounts of memory not released to the system from Firefox. Also, I observed that even after this, there was still a small amount of freed memory that never would get released.
The method I used to demonstrate this was thus:
(All memory monitoring was done using OS X Activity Monitor)
I opened an instance of Firefox with a session of 97 tabs, (call it Firefox 1) and loaded all the tabs. After settle-down, I removed all tabs but 1. After settle-down, recorded the amount of memory this instance of Firefox was using.
I then opened another instance/profile of Firefox (call it Firefox 2), which was for the sole purpose of using up available memory to bring the system into a state of running out of memory. There were no measurements taken from this instance. This was opened with a session of 376 tabs, which would begin loading on startup.
I then recorded the changes I observed in Activity Monitor for memory usage in Firefox 1, and the concurrent swap memory. In some cases I observed that over 300 MB had already been transferred to swap, while there still remained over 300 MB of memory that had not yet been released from Firefox 1.
Details of my findings are attached, along with test sessions and demo extension to force memory purge.
If using the demo extension, make sure addon bar is enabled and look for "Trigger Memory Release" menu button. Click on "nsIMemoryReportManager.resident" to trigger a purge.
Created attachment 729920 [details]
Session - 97 tabs for Firefox test instance
Created attachment 729923 [details]
Extension to force memory release
The bigger session for the utility instance was too big to attach:
What version of MacOS are you running, and what is your hardware?
OS X 10.7.5
Model Name: Mac mini
Model Identifier: Macmini5,2
Processor Name: Intel Core i5
Processor Speed: 2.5 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Memory: 4 GB
Boot ROM Version: MM51.0077.B10
SMC Version (system): 1.75f0
Serial Number (system): C07GQ3KHDJD1
Hardware UUID: 089E18A8-92DE-5EA4-90BC-5C62BFF40D5C
Memory allocated by the JS engine is not affected by jemalloc_purge_freed_pages, so this is not a JS bug.
glandium, any wisdom you have to add would be well-received :)