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

[Maciej Stachowiak]

On Oct 9, 2012, at 1:24 PM, Adam Barth <abarth at webkit.org> wrote:

> On Tue, Oct 9, 2012 at 12:17 PM, Antti Koivisto <koivisto at iki.fi> wrote:
>> On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth <abarth at webkit.org> wrote:
>>> This is interesting data, but it seems to be related to whether we
>>> should make the MemoryCache content addressable rather than whether we
>>> should use shared memory to back the MemoryCache when there are
>>> multiple WebProcesses.
>> 
>> It is relevant when considering if and how to share cache data between
>> processes. It is also interesting in single process case. Brady's
>> refactoring should be helpful for both scenarios.
> 
> Content-addressable caches are quite interesting.  There are a couple
> benefits you could hope to achieve:
> 
> 1) Reduced memory usage by deduping cached values.  The data you
> mentioned seems mostly about this benefit.
> 
> 2) Reduced latency by finding increasing the cache hit rate for
> duplicated entries.  This one is trickier without cooperation from the
> server because you don't know the hash of the resource until you've
> already received it.
> 
> We've had a couple of customers ask about (2), but there are some
> tricky security problems because you end up leaking the identity of
> cross-origin resources in the timing channel.  Aiming for (1) also
> carries some of that risk because you'll leak the identity of
> cross-origin resources in the cache eviction channel (which can be
> probed with timing or network traffic), but it's likely not as big a
> problem.

We're mainly interested in (1), with the corollary of greater cache effectiveness at equivalent total cache size (so you can think of the benefit as an indirect speed win rather than as just a memory win).

Regards,
Maciej