ASSIGNED 98539
Refactor resource loading to allow for out-of-process loading and memory caching
https://bugs.webkit.org/show_bug.cgi?id=98539
Summary Refactor resource loading to allow for out-of-process loading and memory caching
Brady Eidson
Reported 2012-10-05 11:21:36 PDT
Refactor resource loading to allow for out-of-process loading and memory caching. This is to support https://bugs.webkit.org/show_bug.cgi?id=98537
Attachments
Patch v1 (for EWS) (40.90 KB, patch)
2012-10-08 10:34 PDT, Brady Eidson
buildbot: commit-queue-
Patch v2 - Quell the obvious EWS warnings (41.46 KB, text/plain)
2012-10-08 11:19 PDT, Brady Eidson
no flags
instrumentation patch for duplicate cache resources (2.92 KB, patch)
2012-10-09 07:44 PDT, Antti Koivisto
no flags
Dimitri Glazkov (Google)
Comment 1 2012-10-05 11:23:42 PDT
Is this in WebCore?
Adam Barth
Comment 2 2012-10-05 11:32:35 PDT
When we experimented with moving the MemoryCache out of process, it looked like a net loss. I'm curious what experiments you've run that show that having the MemoryCache out of process is a win.
Brady Eidson
Comment 3 2012-10-05 11:34:26 PDT
(In reply to comment #1) > Is this in WebCore? Yes.
Brady Eidson
Comment 4 2012-10-05 11:36:24 PDT
(In reply to comment #2) > When we experimented with moving the MemoryCache out of process, it looked like a net loss. I'm curious what experiments you've run that show that having the MemoryCache out of process is a win. Net loss in what regard? Memory use? Performance? Etc? Please share data if you have it. Experimentally we know that running multiple WebProcesses with individual caches uses unacceptably more memory and - without disk caching - leads to slower page load speeds.
Brady Eidson
Comment 5 2012-10-05 11:37:07 PDT
(In reply to comment #3) > (In reply to comment #1) > > Is this in WebCore? > > Yes. Let me elaborate on this - Refactoring will have to occur in WebCore to support this. But the feature itself will be in WebKit2.
Adam Barth
Comment 6 2012-10-05 11:43:11 PDT
> Net loss in what regard? Memory use? Performance? Etc? Please share data if you have it. We conducted the experiments in 2007 and then again in 2009. I don't think we have the data around anymore. > Experimentally we know that running multiple WebProcesses with individual caches uses unacceptably more memory and - without disk caching - leads to slower page load speeds. Yes, that's correct. The approach we use in Chromium is to have a global budget for memory cache. We then apportion the budget to the various render processes based on a number of heuristics. For example, foreground render processes get a bigger budget than background processes. When a process is moved to the background, we ask it to reduce its memory cache usage if the budget is tight. See http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/web_cache_manager.h http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/web_cache_manager.cc for details. As I recall, the experiments we ran showed that there wasn't much duplication of cached items across render processes, so it wasn't worth using shared memory to unify the caches.
Brady Eidson
Comment 7 2012-10-08 10:34:57 PDT
Created attachment 167558 [details] Patch v1 (for EWS) Not marking for review just yet, as I expect to get EWS fallout that I'll need to attend to.
Brady Eidson
Comment 8 2012-10-08 10:36:36 PDT
(In reply to comment #6) > > Net loss in what regard? Memory use? Performance? Etc? Please share data if you have it. > > We conducted the experiments in 2007 and then again in 2009. I don't think we have the data around anymore. > ... > As I recall, the experiments we ran showed that there wasn't much duplication of cached items across render processes, so it wasn't worth using shared memory to unify the caches. We have data that shows it is worth it for our expectations in WebKit 2. I've attached a patch here to get the EWS ball rolling, but am also sending out an email to webkit-dev since you've requested it.
WebKit Review Bot
Comment 9 2012-10-08 10:36:44 PDT
Attachment 167558 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/CMakeLists.txt', u'Source/W..." exit_code: 1 Source/WebCore/loader/cache/CachedImage.cpp:39: Alphabetical sorting problem. [build/include_order] [4] Source/WebCore/loader/ResourceBuffer.h:49: More than one command on the same line in if [whitespace/parens] [4] Total errors found: 2 in 28 files If any of these errors are false positives, please file a bug against check-webkit-style.
Build Bot
Comment 10 2012-10-08 10:55:25 PDT
Comment on attachment 167558 [details] Patch v1 (for EWS) Attachment 167558 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/14207560
Brady Eidson
Comment 11 2012-10-08 11:19:19 PDT
Created attachment 167569 [details] Patch v2 - Quell the obvious EWS warnings
Brady Eidson
Comment 12 2012-10-08 14:21:11 PDT
Meant to put that patch on 98541, and to actually submit to EWS. *sigh*
Antti Koivisto
Comment 13 2012-10-09 07:44:23 PDT
Created attachment 167753 [details] instrumentation patch for duplicate cache resources Related to this work, here is a patch that can be used to instrument the cache for duplicate resources in different URLs.
Note You need to log in before you can comment on or make changes to this bug.