At the end of the Mozilla membuster test, FastMalloc has around 90M that is returnable to the system but hasn't been. We normally limit aggressiveness of our memory returning to avoid performance degradation. But we might be able to track when a very large amount of memory has been freed and scavange more aggressively in such cases only.
I am looking into this. The brute force method of releasing lots of memory during webview teardown doesn't seem to work the way we want. I am working on teaching FastMalloc how to keep better track of its which memory it returned to the system and which memory it has free but still allocated to us.
simply adding a bool to track which spans are returned to the system is a .5% sunspider regression
returning spans that are being merged to spans that have already been returned is an additional 1% sunspider regression.
Without these improvements we don't keep accurate count of how much memory we have already returned to the system so any heuristic based on what memory we think we have will be skewed.
On sunspider ~40% of the pages merged are returned memory so the skew is significant.
As a side note, tracking and merging returned pages is also part of the problem with returning memory on windows.
*** This bug has been marked as a duplicate of bug 28676 ***