wicg/performance-memory

performance-memory

Proposal to expose more detailed memory metrics to the web.

Authors: [email protected], [email protected]

performance-memory's Issues

The specification uses a dictionary, but Chrome does not

In Chrome, the IDL appears to use a MemoryInfo interface: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/timing/MemoryInfo.idl?q=MemoryInfo.idl&sq=package:chromium&l=1

A dictionary has significantly different semantics, e.g. you can modify the properties of dictionaries, and they use data properties instead of the getters of an interface.

This specification should have valid IDL

https://github.com/erikchen/performance-memory/blob/master/explainer.md#proposed-api does not contain valid IDL, but appears to gesture toward it by using the term "dictionary" (see #3).

Feedback from GSuite & Gmail

Tim, Hannes and I spoke with the GSuite & Gmail teams offline. They were happy with the introduction of PrivateMemoryFootprint, but had concerns about the "accurate or null" proposal. Their concern was that their properties might disproportionately end up in the "null" bucket, due to usage patterns of their users.

They suggested the following:

• Assuming that there are a process contains multiple top level frames from the same origin...
• Continue to report stats [knowing that they will be inflated]
• But also include: numberOfSharedRenderers

Users that want the "accurate or null" property can simply ignore results with numberOfSharedRenderers > 1.

There's a slight caveat - as per discussion with Boris Z on blink-dev@chromium, we will actually need to report:

• numberOfNonEmptyFrameTrees

which has different semantics, but will usually provide a similar result. This seems like a reasonable request.

Tim, Hannes and I brainstormed how to appropriately change the API to support this without introducing a foot-gun. It seems likely that some developers will accidentally ignore the numberOfNonEmptyFrameTrees field and get incorrect results.

We failed to come up with an answer that wasn't too clunky, so we're going to just drop in the field for now, and consider the ergonomics later.

SharedWorker and ServiceWorker memory attribution

Appendix C suggests shared memory should be attributed to a single owner:

https://github.com/WICG/performance-memory/blob/master/explainer.md#-appendix-c---shared-memory

How would this work for web platform features like SharedWorker and ServiceWorker?

SharedWorker instances may be attached to multiple iframes of the same origin across any number of processes. None of these connections is considered "primary". Where is the SharedWorker memory attributed?

ServiceWorker threads spawn in reaction to events from clients like iframes, but is not directly connected to any clients. The ServiceWorker is considered to "control" clients, but same-origin clients that are not controlled can also activate the ServiceWorker using postMessage, etc. The ServiceWorker can also be activated without any client interaction via things like push messages or background sync. How is this ServiceWorker memory attributed?

One possible solution is to convert the proposal to report memory per environment instead of per "iframe". An environment is:

https://html.spec.whatwg.org/multipage/webappapis.html#environment

Each window, iframe, worker (dedicated/shared/service) is a separate environment. This would avoid having to deal with how these environments interconnect.

Feedback from Web Performance Working Group

• It would be helpful to provide a list of concrete use cases [e.g. problems observed in the wild]
• The current proposal is too proscriptive w.r.t. implementation/definition of memory.
• Memory is functionally a signal used to indicate growth. The spec could define hints [e.g. node count, array buffers, etc.] as to what should fuel that signal.
• Given the difficulty of coming up with an API that is implementable by browsers and provides utility for web developers, may be helpful to consider (MVP - 1). If browsers cannot implement (MVP-1), then there will be no way to go forward.
• Making the API async would be helpful for some browser vendors.
• We considered utility in returning cross-origin iframe memory [perhaps separately]. This isn't actionable by web developers [there's nothing they can do to fix the issue] but perhaps it would drive ecosystem change?

Suggest non-goal around comparability

I think any spec in this space should make it very clear that the API cannot be reliably used to compare numbers across browsers, OSes, or possibly even across different versions of a given browser. For example, if Chrome makes an implementation change one release that moves some graphics related memory from the GPU process into the renderer process, developers should not treat this as a regression in their site. Similarly, as tempting as it will be, you can't meaningfully benchmark browsers against eachother based on the data from this API.

So maybe even word this positively as a Goal like: "Enable memory usage comparison between two versions of an application running in substantially identical environments". And then make a recommendation of the properties developers should use to key their aggregation of data against. Eg: comparisons are likely valid only across environments where the following properties are identical:

• navigator.userAgent
• window.innerWidth, window.innerHeight
• window.devicePixelRatio

In Chrome this is [NoInterfaceObject]. Should it be?

[NoInterfaceObject] is generally deprecated and should be avoided. But, maybe this is a legacy use case where we'd want to keep it.

Feedback from Apple

I've been discussing the proposal with some Apple engineers. The preliminary feedback has been really helpful, and I wanted to start updating the spec based on that feedback.

• The current proposal relies on the assumption that the browser has process-isolation of origins. This is not the case for all browsers.
• To prevent exposing details of GC timings, we need to [at a minimum] return time-quantized values. [e.g. only update the value every 30 seconds].
• Adding normally distributed noise will have minimal affect on aggregated metrics and will potentially reduce information exposed to malicious attackers.
• Implementations may return null when unable to compute an accurate number. But this means that transitions from [null to non-null] or [non-null to null] measurements may itself expose information. This requires careful privacy consideration on a per-implementation basis.

Should we archive this repo?

In light of:
mozilla/standards-positions#85 (comment)

Should we archive this repo?

Does window.performance.memory === window.performance.memory hold?

This is an important thing to include in any spec.

The answer should be yes, if at all possible.

Feedback from Facebook

This is feedback from Benoit and Vlad, Nate will reply separately.

We really like this proposal: private memory footprint makes a lot of sense, "accurate or null" is a huge improvement, and it seems like most privacy issues have been addressed.

Things that are unclear to us:

For privateMemoryFootprint, totalJSHeapSize, and usedJSHeapSize we only have accurate accounting when the process is hosting a single top level frame. As such, we return null anytime the process is hosting more than a single top level frame.

What will be returned when two Facebook.com tabs are in the same render process? We would prefer null for this situation, since it is very hard to interpret a single memory usage number from multiple tabs.

One strange thing in this proposal is that web authors will need to handle that some instances of Chrome (e.g. on mobile) won’t have full site isolation and others (e.g. on desktop) will. It’s a bit ugly, but they can detect this by looking at cases where all the values in that page ended in four zeros. If all calls to performance.memory result in quantized values, then it’s almost guaranteed to be the quantized numbers.

This is from the proposal in the Google Doc https://docs.google.com/document/d/1iC9-sra-vdz0c18qM9H_El_k4yGzd6TdIItIfs3p-8Q/edit#

So does this mean that mobile Chrome will ALWAYS quantize and delay memory measurements?
What if there is a single tab in mobile Chrome, will it return the accurate measurement?
In the past, we have used the quantized/delayed performance.memory API and have not gotten benefit out of it. So we would prefer "accurate or null" again -- either the measurement is from a single tab or it is null.

The results are non-null if and only if all frames hosted by the process are part of a single frame tree.

Can you clarify, perhaps in the explainer, exactly what this means for the following scenarios:

• Page with a same-origin iframe
• Page with a foreign-origin iframe but OOPIF enabled

Our suggestions:

• The spec should have a provision to allow the browser to return NULL at its discretion to protect the user's privacy. So for example, the browser might want to return null from the memory API if a foreign origin IFRAME was every loaded by the page (i.e. if the renderer process was tainted with foreign-origin data).
  Example attack: A malicious top-level frame measures its memory usage, then loads an IFRAME pointed to a target origin, then destroys this IFRAME and measures memory again, relying on the browser to not have freed all memory from the foreign origin immediately. This would allow the malicious top-level frame to obtain information about the target page, e.g. whether the user was logged into the target origin.
• Is it possible to get additional categories in the future to make the memory information more actionable? Examples: memory used by HTML nodes, CSS, Canvas, audio/video elements, etc. For instance, we have had situations where React was leaking nodes, and this type of information could have made it easier to find the cause.