Bug 22275 - Return memory more aggressively when large amount of memory has been freed
Summary: Return memory more aggressively when large amount of memory has been freed
Status: RESOLVED DUPLICATE of bug 28676
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Template Framework (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Stephanie Lewis
Depends on:
Reported: 2008-11-14 20:06 PST by Maciej Stachowiak
Modified: 2010-01-05 12:34 PST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Stachowiak 2008-11-14 20:06:42 PST
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.
Comment 1 Stephanie Lewis 2008-11-14 20:15:01 PST
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.
Comment 2 Stephanie Lewis 2008-11-19 23:14:42 PST
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.
Comment 3 Geoffrey Garen 2010-01-05 12:34:24 PST

*** This bug has been marked as a duplicate of bug 28676 ***