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/e380f56c-526d-5717-d182-79ff9d77a3cb%40chromium.org.
