Intent to Experiment: Keep strong references to resources in Blink memory cache

[Jiacheng Guo]

Contact emails

g...@google.com

Explainer

https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing

Specification

The feature is not web-spec related.

Design docs

https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing

Summary

To measure the impact of garbage collection on Blink memory cache and potential performance boost, we plan to keep strong references to loaded resources in the Blink memory cache. The change will serve as an estimation only project to collect data about the maximal cache hit rate with all resources available.

Blink component

Blink>Loader

TAG review

TAG review is not required since the experiment changes the internal behavior of renderer and is transparent to the websites and web developers.

Risks

Interoperability and Compatibility

Resource reference lifetime does not affect the behavior of the browser. We do not expect there to be interoperability or compatibility issues.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

The change does not modify the behavior of web APIs

Goals for experimentation

The four configurations will be launched on dev/canary. The combinations are: * The control group. No strong reference to resources. * Save strong references for all resources of all types for all the pages. * Save strong references for only script, fonts and stylesheets for all pages. * Save strong references for all resources for only one page. * Save strong references for only script, fonts and stylesheets for only one page. We will evaluate the following metrics under different configurations * Core web browsing metric (FCP/LCP etc) * Cache hit rate: Blink.MemoryCache.RevalidationPolicy * Memory footprint * Crash Rate

Reason this experiment is being extended

Ongoing technical constraints

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No, resource reference lifetime in blink is invisible to the websites.

Flag name

MemoryCacheStrongReference for the overall configuration. MemoryCacheStrongReferenceSingleUnload and MemoryCacheStrongReferenceFilterImages for sub configurations

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1409349

Estimated milestones

The feature is for experiment only. We do not expect to launch it to stable as it is. If the experiment provides positive results, we will move on to further refine the resource lifetime management strategy in Blink. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5196823129489408

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Thanks for sending the intent and for experimenting with the MemoryCache!

On Fri, Mar 17, 2023 at 7:08 PM 'Jiacheng Guo' via blink-dev <blin...@chromium.org> wrote:

Contact emails

g...@google.com

Explainer

https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing

Specification

The feature is not web-spec related.

The situation as I remember it is a bit more complex than that :)

I think the memory cache is defined for images, but not for other resource types.

So if we end up changing the behavior for images, it'd be good to see if we can reflect that behavior change in the spec.

And ideally, it'd be great if we're able to actually specify the behavior of the memory cache once we figure out where we want it to land, as I believe it is observable. (Through ResourceTiming, as well as timing in general).

  

Design docs

https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing

Summary

To measure the impact of garbage collection on Blink memory cache and potential performance boost, we plan to keep strong references to loaded resources in the Blink memory cache. The change will serve as an estimation only project to collect data about the maximal cache hit rate with all resources available.

Blink component

Blink>Loader

TAG review

TAG review is not required since the experiment changes the internal behavior of renderer and is transparent to the websites and web developers.

Risks

Interoperability and Compatibility

Resource reference lifetime does not affect the behavior of the browser. We do not expect there to be interoperability or compatibility issues.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

The change does not modify the behavior of web APIs

Goals for experimentation

The four configurations will be launched on dev/canary. The combinations are: * The control group. No strong reference to resources. * Save strong references for all resources of all types for all the pages. * Save strong references for only script, fonts and stylesheets for all pages. * Save strong references for all resources for only one page. * Save strong references for only script, fonts and stylesheets for only one page.

Can you explain the differences between the "for all the pages" and the "only one page" variants?

 

We will evaluate the following metrics under different configurations * Core web browsing metric (FCP/LCP etc) * Cache hit rate: Blink.MemoryCache.RevalidationPolicy

Could we also count how many resources are no longer loaded over the network? (so are now a MemoryCache HIT that were formerly an HTTP cache MISS)

 

* Memory footprint * Crash Rate

Reason this experiment is being extended

Ongoing technical constraints

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No, resource reference lifetime in blink is invisible to the websites.

Flag name

MemoryCacheStrongReference for the overall configuration. MemoryCacheStrongReferenceSingleUnload and MemoryCacheStrongReferenceFilterImages for sub configurations

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1409349

Estimated milestones

The feature is for experiment only. We do not expect to launch it to stable as it is. If the experiment provides positive results, we will move on to further refine the resource lifetime management strategy in Blink. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5196823129489408

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NwNzokqhvwtnrV-J-8BeMeRjfC-cvkXMBmZYK4Vej%3DX%2Bg%40mail.gmail.com.

[Jiacheng Guo]

In the "for all the pages" scenario, we will keep strong references for the resources for five minutes when each page unloads.

In the "only one page" scenario, when a page unloads, it will override the saved strong references.

The UMA "Blink.MemoryCache.CrossDocumentCachedResource2" records how many resources are reused among different documents. We will compare this metric between the control group and the experiments.

[Noam Rosenthal]

On Mon, Mar 20, 2023 at 11:47 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for sending the intent and for experimenting with the MemoryCache!

On Fri, Mar 17, 2023 at 7:08 PM 'Jiacheng Guo' via blink-dev <blin...@chromium.org> wrote:

Contact emails

g...@google.com

Explainer

https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing

Specification

The feature is not web-spec related.

The situation as I remember it is a bit more complex than that :)

I think the memory cache is defined for images, but not for other resource types.

So if we end up changing the behavior for images, it'd be good to see if we can reflect that behavior change in the spec.

And ideally, it'd be great if we're able to actually specify the behavior of the memory cache once we figure out where we want it to land, as I believe it is observable. (Through ResourceTiming, as well as timing in general).

See spec meta-bug for context: https://github.com/whatwg/html/issues/6110

There are lots of existing interop issues around memory cache, we should try to make things better there (or at least not make them worse...) interoperability-wise.

[Mike Taylor]

What are the desired timelines for the experiments?

The design doc mentions only testing in dev and canary - do you plan to eventually experiment in beta or stable?

[Jiacheng Guo]

The spec says:

User agents may copy entries from one Document object's list of available images to another at any time

I believe the change is in line with the spec. It makes this behavior more frequent. The spec does not define behavior for other resources for now. The other involved resource types are stylesheet, fonts and scripts. It would be desirable to add a description about MemoryCache for these resources in the spec and allow cross-document reusing. For now I believe it is acceptable to launch the experiment in dev and canary.

We plan to launch the experiment in dev and canary in April. There are concerns about the memory footprint increase introduced by the change so we decide to hold the experiment in beta or stable. The experiment will provide data for the tradeoff between memory consumption and load speed. If the experiments in dev and canary show a positive impact on page loading metrics, we plan to refine the resource saving strategy and launch with the new implementation.

[Mike Taylor]

LGTM to experiment in canary/dev. For clarity, how long do you plan to experiment?

(I don't think you need an LGTM in this case, https://www.chromium.org/blink/launching-features/#origin-trials mentions needing an LGTM to experiment on beta or stable - but thanks for sending the intent!).

[Camille Lamy]

In the S&P review, we were wondering if the memory pressure case event was an event exposed to the web page or an internal Chrome event? In the latter case, there may be a potential for XS-Leaks.

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jiacheng Guo]

It's an internal event and the memory cache is already using it for clearing resources. The code can be found here:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/loader/fetch/memory_cache.cc;l=99;bpv=1;bpt=1?q=memory_cache.cc&ss=chromium

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Hiroshige Hayashizaki]

As for MemoryCache interoperability, I expect this experiment doesn't make things worse, because this experiment doesn't change the cache hit logic, and only changes the lifetime of resources.

There will be observable changes (e.g. by observing which resources are loaded from the network), but they are within the cache's discretion (to decide which resources to be kept or evicted).

As for https://html.spec.whatwg.org/multipage/images.html#list-of-available-images, I think Chromium doesn't perform the following spec step (with or without this experiment):

> User agents may copy entries from one Document object's list of available images to another at any time

but this experiment is spec-conformant because this experiment adjusts image resource lifetime within the specified range -- corresponding to that this experiment would perform the following spec step less frequently:

> User agents may also remove images from such lists at any time (e.g. to save memory).

As for memory pressure events,

• The effect by the memory pressure events in this experiments are more directly observable (e.g. whether the requests are served from network or from cache -- with significant latency differences)
• Than the existing usage of memory pressure events in MemoryCache that Jiacheng mentioned (only clearing some decoded data, resulting in more subtle performance differences, without impacting whether served from network or cache).

I'm not sure whether this can expose something though.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NyVAiEdoNmFzMDR8_kg28uHB5ACJ8bfEBrf2c3Su3o3-g%40mail.gmail.com.