Intent to Implement: JavaScript Memory API

[Ulan Degenbaev]

Contact emails

ul...@google.com

Explainer

https://github.com/ulan/javascript-agent-memory/blob/master/explainer.md

Design docs/spec

N/A

TAG review

https://github.com/w3ctag/design-reviews/issues/386

Summary

The feature adds a performance.measureMemory() function that estimates the total size of JavaScript objects that the calling context can access.

Motivation

Web developers need an API for measuring memory usage of their applications in production. The use cases include a) analysis of correlation between memory usage and user metrics, b) detection of memory regressions, c) evaluation of feature launches in A/B tests, d) memory optimization.

Currently web developers resort to the non-standard performance.memory API that is used in 20% of page loads in Chrome.

Risks

Interoperability and Compatibility

The API was designed to be secure and to avoid information leak from foreign origins. As a trade-off this complicates the implementation. There is risk that the API may be difficult to implement in other browsers.

Note however that this API is the simplest memory measurement API to implement given the security constraints. If it is impossible, then memory measurement in general is not possible for web platform.

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: Positive

Developers from Gmail, Google Docs/Slides/Sheet, Facebook, YouTube contributed use cases for memory measurement API.

The proposal was presented at WebPerf WG F2F June 2019 meeting and received positive feedback from developers.

Ergonomics

None

Activation

None

Security

See https://github.com/ulan/javascript-agent-memory/blob/master/explainer.md#security-considerations

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

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5685965186138112

[Daniel Bratell]

As you mention. memory usage can already be found in performance.memory (mentioned at https://developer.mozilla.org/en-US/docs/Web/API/Performance as a Chrome only extension) and there has been a lot of discussion about that one.

My take on this is that memory usage numbers are not, and will never be, fully comparable between browser engines so trying to standardize it is futile. It is a very user agent specific piece of debug information and that 20% of page loads (hmm, facebook and google?) use it is scary. Still, such debug information is valuable so I don't mind that it's available, as long as it's not something web pages ever depend on. How? Not sure.

So if performance.memory will forever be a Chromium extension, and this will, I believe, suffer the same fate, could this new method/number also be in performance.memory so that there is only one Chromium extension instead of two?

(bike shedding; I think the idea is good)

/Daniel

--
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/CABNJt2%2BXZFRX7tbBVvKTW7TegysYpjVNQdja7jYs3cTYuG%2BabA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Ulan Degenbaev]

Hi Daniel,

We do not want to make the numbers comparable between different browsers (see non-goals). Web developers will use the API to track memory regressions on specific browsers based on navigator.userAgent.

If standardization of this proposal succeeds, then it will allow us to deprecate and remove the existing performance.memory. So in the best case we will have zero Chromium extensions.

I think the main issues that prevented standardization of performance.memory were security and dependency on the underlying process model (how pages are mapped to processes/heaps). That's very difficult to spec properly.

The new proposal resolves these issues by restricting the result to the same-origin realms of the current JavaScript agent. I hope that gives us better chances with standardization.

Cheers,

Ulan.

[Yoav Weiss]

Hey Daniel,

Note that this was discussed in last week's WebPerfWG F2F meeting. (minutes)

Another worthy note is that the target use case here is not to compare memory consumption between browsers, but to compare memory consumption between a site and itself over time in a single browser, in order to be able detect memory leaks in the wild. 

During the F2F, all browser vendors (as well as API users) in the room understood the use-case and showed a fair amount of enthusiasm towards solving it. The API design solves several of the security issues that exist with the proprietary one that made other vendors reluctant to implement it. The main point of discussion for this use-case was whether it is useful enough as it's currently defined (exposing live memory) or it should be further augmented to expose GCed memory, which would make drawing conclusions from the results easier, but runs a risk of exposing GC times and related side channels.

Cheers,

Yoav

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABNJt2%2Byg-t9BvT-%2BYJ3q-VRawczJrKFSm8NyieNmKx7XEiChA%40mail.gmail.com.