Bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching
Summary: Refactor resource loading to allow for out-of-process loading and memory caching
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Brady Eidson
URL:
Keywords:
Depends on: 98541 98952 98976 100355 100479
Blocks: 98537
  Show dependency treegraph
 
Reported: 2012-10-05 11:21 PDT by Brady Eidson
Modified: 2012-10-26 00:55 PDT (History)
12 users (show)

See Also:


Attachments
Patch v1 (for EWS) (40.90 KB, patch)
2012-10-08 10:34 PDT, Brady Eidson
buildbot: commit-queue-
Details | Formatted Diff | Diff
Patch v2 - Quell the obvious EWS warnings (41.46 KB, text/plain)
2012-10-08 11:19 PDT, Brady Eidson
no flags Details
instrumentation patch for duplicate cache resources (2.92 KB, patch)
2012-10-09 07:44 PDT, Antti Koivisto
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brady Eidson 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
Comment 1 Dimitri Glazkov (Google) 2012-10-05 11:23:42 PDT
Is this in WebCore?
Comment 2 Adam Barth 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.
Comment 3 Brady Eidson 2012-10-05 11:34:26 PDT
(In reply to comment #1)
> Is this in WebCore?

Yes.
Comment 4 Brady Eidson 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.
Comment 5 Brady Eidson 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.
Comment 6 Adam Barth 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.
Comment 7 Brady Eidson 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.
Comment 8 Brady Eidson 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.
Comment 9 WebKit Review Bot 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.
Comment 10 Build Bot 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
Comment 11 Brady Eidson 2012-10-08 11:19:19 PDT
Created attachment 167569 [details]
Patch v2 - Quell the obvious EWS warnings
Comment 12 Brady Eidson 2012-10-08 14:21:11 PDT
Meant to put that patch on 98541, and to actually submit to EWS.  *sigh*
Comment 13 Antti Koivisto 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.