Fixed a portion of:
authorggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 18 Feb 2010 22:15:34 +0000 (22:15 +0000)
committerggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 18 Feb 2010 22:15:34 +0000 (22:15 +0000)
commit4138a1234e04045812aead9af149d82fa6992bf3
treecce333b51c8b78d534524d5e0e28e2dab6be72b0
parent476fea8c3e88b4a23f02d37943727400b3ac2167
Fixed a portion of:
<rdar://problem/7165917> | https://bugs.webkit.org/show_bug.cgi?id=28676
Safari 4 does not release memory back to the operating system fast enough (28676)

Reviewed by Oliver Hunt.

This patch fixes a surprisingly common edge case in which the page heap
would have only one free span, but that span would be larger than the
minimum free size, so we would decide not to free it, even though it
could be as large as 100MB or more!

SunSpider reports no change on Mac or Windows.

* wtf/FastMalloc.cpp:
(WTF::TCMalloc_PageHeap::scavenge): Call shouldContinueScavenging() instead
of doing the math ourselves. Don't keep a local value for pagesDecommitted
because that lets free_committed_pages_ be wrong temporarily. Instead,
update free_committed_pages_ as we go. ASSERT that we aren't releasing
a span that has already been released, because we think this is impossible.
Finally, don't be afraid to release all free memory in the page heap when
scavenging. We only scavenge after 5 seconds of the application's working
set not growing, and we keep both thread caches and a central cache on
top of the page heap, so the extra free pages in the page heap were just
overkill.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@54988 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JavaScriptCore/ChangeLog
JavaScriptCore/wtf/FastMalloc.cpp