I'm not super familiar with the MemoryCache but my understanding was that some recent work was made to make it work more like an index of in-use resources rather than a cache (i.e. it holds weak references to resources).

This makes me feel like its max size is a bit meaningless, but hiroshige will know more.

The MemoryCache capacity (controlled by the WebCacheManager) currently only affects whether to prune decoded data (via Resource::DestroyDecodedDataIfPossible()), i.e. decoded data of images and CSSs, so increasing the capacity might avoid re-decoding of images etc., but doesn't affect the MemoryCache hit rate.

I'm wondering how often this happens and how expensive eviction ends up being.

Anecdotally, the hit rate for certain resources seem relatively low. Are fonts considered "decoded" and therefore subject to eviction? What other resources can be evicted?

Hiroshige: 

Could you consider adding more metrics?

Questions that seem interesting to answer:
 - How much of the MemoryCache is used?
 - How often do we need to evict data with breakdowns per resource type?
 - How often did we have to re-decode these evicted resources? How expensive was it?
 - How often do we evict resources while doing a same-origin navigation (i.e. resources that would have been useful for the destination page)?

I think this could be more about how we want to keep the resources during page load, I suspect that increasing max size wouldn help a lot in the new cache model.  We probably need to consider having somethibg along this in our roadmap.

kinuko@, what's the status? Do you want to own this issue?

By the way, I've noticed the memory cache sometimes greatly exceeds the limits communicated by the browser. Here's a graph of one MemoryCache instance for example. Dotted line is the policy; blue line is the memory cache's size. In the same session there are other memory caches which are under capacity; this is one extreme example I picked to illustrate.

You can see sometimes this graph makes tremendous dives as resources are pruned, only to consume a similar amount of memory soon after (x-axis is memory cache ops for a whole session, not time, so it's not exact but the memory caches are busy enough it's ~= time.)

I think this behavior arises because the MemoryCache's recency heuristics take precedence over the browser's size limits. What's interesting is that situation can persist for a long time for the active tab's memory cache.

Deleted: memory_cache_no_limits.png 47.8 KB

	memory_cache_no_limits.png 47.8 KB View Download

Possible causes for #12 are:

(A) Working as intended. If MemoryCache purges all prunable decoded data and still the total size exceeds the capacity, then size() is expected to exceeds the capacity. The MemoryCache has no control over the remaining bytes (==size()), because they are kept alive somewhere else.
(B) The MemoryCache bloat occurs during page load, due to the mechanism where MemoryCache keeps Resources that are loaded in the previous page alive.
(C) Something wrong due to another bug.

MemoryCache stats by memory-infra tracing (about:tracing => select memory-infra category manually and record => see renderer process > "Memory per component" > web_cache) will provide more detailed information -- list of objects counted in MemoryCache size, their sizes and number of clients in reason_not_deletable column. If reason_not_deletable contains "hasClients", then the cause of the comment #12 will be (A).

As for metrics for pruning, currently MemoryCache does NOT have detailed knowledge, especially e.g.
- How much of MemoryCache size are prunable decoded data.
- What kind of decoded data are purged, and thus whether the purged data is re-generated again.
These are mainly controlled by CSS and Image code (outside loader).
MemoryCache only knows how many bytes are (estimated to be) removed after actual pruning.
So to add detailed metrics on pruning, we have to deep dive into CSS and image code.

For (B) the flag is disabled by default so we shouldn't be explicitly preserving any resources if I'm reading the flags right.  (It will still be useful to see how the memory usage changes by setting different flags for chrome://flags/#save-previous-document-resources-until)