Title: [184720] trunk/Source/WebCore
Revision
184720
Author
cdu...@apple.com
Date
2015-05-21 10:45:21 -0700 (Thu, 21 May 2015)

Log Message

Regression(r179293): We no longer call destroyDecodedData() on CachedResources on memory pressure
https://bugs.webkit.org/show_bug.cgi?id=145270
<rdar://problem/20734901>

Reviewed by Andreas Kling.

We no longer call destroyDecodedData() on CachedResources on memory
pressure after r179293. In r179293, we started calling
MemoryCache::evictResources() on memory pressure instead of
MemoryCache::pruneToPercentage(0). However, unlike
MemoryCache::pruneToPercentage(), it appears
MemoryCache::evictResources() removes the CachedResources from the
memory cache without calling destroyDecodedData() on them.
This caused a regression on Membuster.

This patch now calls MemoryCache::pruneLiveResourcesToSize(0) on
critical memory pressure, instead of evictResources(). We don't need to
call pruneDeadResourcesToSize(0) here because the non-critical memory
pressure handler already takes care of this.

During local testing, this change seemed to decrease the overall memory
usage of WebProcesses by ~10MB on Membuster (tested on Yosemite).

* platform/MemoryPressureHandler.cpp:
(WebCore::MemoryPressureHandler::releaseNoncriticalMemory):
(WebCore::MemoryPressureHandler::releaseCriticalMemory):

Modified Paths

Diff

Modified: trunk/Source/WebCore/ChangeLog (184719 => 184720)


--- trunk/Source/WebCore/ChangeLog	2015-05-21 17:36:32 UTC (rev 184719)
+++ trunk/Source/WebCore/ChangeLog	2015-05-21 17:45:21 UTC (rev 184720)
@@ -1,3 +1,32 @@
+2015-05-21  Chris Dumez  <cdu...@apple.com>
+
+        Regression(r179293): We no longer call destroyDecodedData() on CachedResources on memory pressure
+        https://bugs.webkit.org/show_bug.cgi?id=145270
+        <rdar://problem/20734901>
+
+        Reviewed by Andreas Kling.
+
+        We no longer call destroyDecodedData() on CachedResources on memory
+        pressure after r179293. In r179293, we started calling
+        MemoryCache::evictResources() on memory pressure instead of
+        MemoryCache::pruneToPercentage(0). However, unlike
+        MemoryCache::pruneToPercentage(), it appears
+        MemoryCache::evictResources() removes the CachedResources from the
+        memory cache without calling destroyDecodedData() on them.
+        This caused a regression on Membuster.
+
+        This patch now calls MemoryCache::pruneLiveResourcesToSize(0) on
+        critical memory pressure, instead of evictResources(). We don't need to
+        call pruneDeadResourcesToSize(0) here because the non-critical memory
+        pressure handler already takes care of this.
+
+        During local testing, this change seemed to decrease the overall memory
+        usage of WebProcesses by ~10MB on Membuster (tested on Yosemite).
+
+        * platform/MemoryPressureHandler.cpp:
+        (WebCore::MemoryPressureHandler::releaseNoncriticalMemory):
+        (WebCore::MemoryPressureHandler::releaseCriticalMemory):
+
 2015-05-21  Said Abou-Hallawa  <sabouhall...@apple.com>
 
         SVG as image uses very tiny default font-size

Modified: trunk/Source/WebCore/platform/MemoryPressureHandler.cpp (184719 => 184720)


--- trunk/Source/WebCore/platform/MemoryPressureHandler.cpp	2015-05-21 17:36:32 UTC (rev 184719)
+++ trunk/Source/WebCore/platform/MemoryPressureHandler.cpp	2015-05-21 17:45:21 UTC (rev 184720)
@@ -95,7 +95,7 @@
     }
 
     {
-        ReliefLogger log("Evict MemoryCache dead resources");
+        ReliefLogger log("Prune MemoryCache dead resources");
         MemoryCache::singleton().pruneDeadResourcesToSize(0);
     }
 }
@@ -110,8 +110,8 @@
     }
 
     {
-        ReliefLogger log("Evict all MemoryCache resources");
-        MemoryCache::singleton().evictResources();
+        ReliefLogger log("Prune MemoryCache live resources");
+        MemoryCache::singleton().pruneLiveResourcesToSize(0);
     }
 
     {
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to