[webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Brady Eidson]

On Oct 8, 2012, at 12:17 PM, Adam Barth <abarth at webkit.org> wrote:

> On Mon, Oct 8, 2012 at 11:49 AM, Brady Eidson <beidson at apple.com> wrote:
>> On Oct 8, 2012, at 11:24 AM, Adam Barth <abarth at webkit.org> wrote:
>>> On Mon, Oct 8, 2012 at 11:14 AM, Brady Eidson <beidson at apple.com> wrote:
>>>> On Oct 8, 2012, at 10:58 AM, Adam Barth <abarth at webkit.org> wrote:
>>>>> When we looked at whether we should add a shared memory cache to
>>>>> Chromium, we came to the conclusion that there wasn't much benefit to
>>>>> having a shared memory cache.  In
>>>>> <https://bugs.webkit.org/show_bug.cgi?id=98541#c4>, you mentioned that
>>>>> you have data showing that a shared memory cache is a win.  Would you
>>>>> be willing to share this data with the WebKit community?
>>>> 
>>>> It's possible the disparity is because of the process model Chromium was focusing on versus the process models we are exploring.
>>>> 
>>>> WebKit 2 is also evolving as an API framework that supports other non-browser clients which might have different caching needs than Chromium has focused on.
>>>> 
>>>> We don't have hard data to share at this time.  A simple experiment one could run to see the type of result we're focusing on would be to open a handful of articles from various top-tier news sites in different tabs and note just how many resources are shared between them.
>>> 
>>> Without data showing that this is a win, adding a shared memory cache
>>> to WebCore seems like over-engineering and unneeded complexity.  We
>>> had the same design instincts as you when we looked at this issue in
>>> Chromium, but we studied the issue (twice actually) and concluded that
>>> the complexity wasn't worth the meager benefits.
>> 
>> There might be some misunderstanding of the specifics of what I'm working on.
>> 
>> I don't plan to add a shared memory cache to WebCore, or even to add an abstraction of "shared memory" directly to WebCore.
>> 
>> I'm working on refactoring the resource loader/cache to support more customization by the embedding port - In this case, WebKit 2.
>> 
>> Traditionally we've supported refactoring WebCore in ways important to an embedding port even if that port has substantially different needs than most mainstream WebCore clients.
>> 
>> I'm not sure that I see how this case is in a different category.
> 
> Would there be any design or implementation constraints on WebCore?
> For example, would WebCore need to understand any concurrency or
> performance issues caused by the memory being shared between
> processes?

For now we think the answer is no, or that any parts that do need to be concerned to be wholly encapsulated within the support for the client model.

Thanks,
~Brady

> 
> Adam