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. On Tue, Mar 21, 2023 at 10:59 PM 'Jiacheng Guo' via blink-dev < [email protected]> wrote: > 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 > > > On Tue, Mar 21, 2023 at 7:45 PM Camille Lamy <[email protected]> wrote: > >> 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! >> On Monday, March 20, 2023 at 3:57:24 PM UTC+1 Mike Taylor wrote: >> >>> 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!). >>> On 3/20/23 10:16 AM, Jiacheng Guo wrote: >>> >>> The spec says: >>> User agents may copy entries from one Document >>> <https://html.spec.whatwg.org/multipage/dom.html#document> object's list >>> of available images >>> <https://html.spec.whatwg.org/multipage/images.html#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. >>> >>> On Mon, Mar 20, 2023 at 10:49 PM Mike Taylor <[email protected]> >>> wrote: >>> >>>> 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? >>>> On 3/17/23 2:08 PM, 'Jiacheng Guo' via blink-dev wrote: >>>> >>>> Contact emails [email protected] >>>> >>>> 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 >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> >>>> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? 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 >>>> <https://chromestatus.com/>. >>>> -- >>>> 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 [email protected]. >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NwNzokqhvwtnrV-J-8BeMeRjfC-cvkXMBmZYK4Vej%3DX%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- > 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NyVAiEdoNmFzMDR8_kg28uHB5ACJ8bfEBrf2c3Su3o3-g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaYce50i4JyT3J8cCP%2BRsa2G%2B47MBQYxewnRviyScwDW%3Dru5Q%40mail.gmail.com.
