Intent to Implement: Memory Pressure API

[Shubhie Panicker]

Contact emails

pani...@chromium.org, fme...@chromium.org

Explainer

Link to explainer: https://github.com/WICG/memory-pressure/blob/master/explainer.md

Summary

A new API to expose the memory pressure signal received by the system to web applications.

This is to enable web apps to be memory conscious and when the system is under pressure - enable them to release memory and avoid allocating memory.

Design doc

Motivation

Memory constraint results in bad user experiences ranging from OOM crashes to user visible jank.

This is further exacerbated on low end devices, particularly in emerging markets.

This signal will enable developers to alleviate system memory pressure and improve the end user experience by adjusting app behavior under memory pressure by:

a) Not doing expensive things

eg. don't show video or load heavy React component [Facebook], don't render left and right docs [AMP]

b) Releasing non-critical resources

eg. unload a Youtube player if it never played [AMP], throw away doc on swipe [AMP], infinite-scroll app will remove items from list [G+]

Furthermore, we want to pursue memory interventions such as suspending and purging memory from tabs. Before we take such measures, developers should be able to gain insight into memory pressure and be given the opportunity to do their part.

Interoperability and Compatibility Risk

Compat risk is none, the event wouldn't fire if not implemented.

Interop risk is moderate: it will depend on how the signal is defined (work in progress) and whether it will based on platform memory pressure signals vs more sophisticated heuristic.

Edge: Public support (TPAC notes)

Firefox: No signals

Safari: Public support (TPAC notes)

Web developers: Positive (positive signals from Facebook, AMP, SOASTA, Akamai  etc.)

Ongoing technical constraints

None

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

Yes.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=708752

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5719614029824000

Requesting approval to ship?

No

[Philip Jägenstedt]

(Intent to Implement needs no LGTM)

The iOS documentation linked in the explainer (yay) says "You can test your app’s behavior under low-memory conditions using the Simulate Memory Warning command in iOS Simulator."

Thinking about debuggability and web-platform-tests, since this is just a simple event, it seems like web developers could test their code by navigator.dispatchEvent. A WebDriver extension or testing API would only differ by having the isTrusted attribute set to true, which doesn't seem important. So, it would be interesting to have a look at why there is special support in the iOS simulator, to decide whether anything like that is needed for the web platform.

[Emily Stark]

This API seems to have some privacy risk (e.g. https://github.com/WICG/memory-pressure/issues/3), perhaps you could add a Privacy and Security Considerations section to the explainer?

[Shubhie Panicker]

On Tue, Apr 11, 2017 at 3:38 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

(Intent to Implement needs no LGTM)

The iOS documentation linked in the explainer (yay) says "You can test your app’s behavior under low-memory conditions using the Simulate Memory Warning command in iOS Simulator."

Thinking about debuggability and web-platform-tests, since this is just a simple event, it seems like web developers could test their code by navigator.dispatchEvent. A WebDriver extension or testing API would only differ by having the isTrusted attribute set to true, which doesn't seem important. So, it would be interesting to have a look at why there is special support in the iOS simulator, to decide whether anything like that is needed for the web platform.

From reading around I think this note is referring to manual local testing / local repro in simulator as opposed to automated testing.

As you indicated, I don't think there is any problem for automated testing for the code path exercised for the web API.

Though we'll be working closely with developer teams (Maps or News), and will identify gaps in testing.

[Shubhie Panicker]

On Fri, Apr 14, 2017 at 3:19 PM, Emily Stark <est...@chromium.org> wrote:

This API seems to have some privacy risk (e.g. https://github.com/WICG/memory-pressure/issues/3), perhaps you could add a Privacy and Security Considerations section to the explainer?

Yep, I'm working on a Privacy / Security doc. 

Regarding this specific issue I asked for clarification on the issue thread, please chime in with details. Thanks!

[Philip Jägenstedt]

On Sat, Apr 15, 2017 at 6:53 AM Shubhie Panicker <pani...@google.com> wrote:

On Tue, Apr 11, 2017 at 3:38 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

(Intent to Implement needs no LGTM)

The iOS documentation linked in the explainer (yay) says "You can test your app’s behavior under low-memory conditions using the Simulate Memory Warning command in iOS Simulator."

Thinking about debuggability and web-platform-tests, since this is just a simple event, it seems like web developers could test their code by navigator.dispatchEvent. A WebDriver extension or testing API would only differ by having the isTrusted attribute set to true, which doesn't seem important. So, it would be interesting to have a look at why there is special support in the iOS simulator, to decide whether anything like that is needed for the web platform.

From reading around I think this note is referring to manual local testing / local repro in simulator as opposed to automated testing.

As you indicated, I don't think there is any problem for automated testing for the code path exercised for the web API.

Though we'll be working closely with developer teams (Maps or News), and will identify gaps in testing.

For web developers it probably suffices to invoke their callbacks and check that their caches are smaller or empty.

Should there be any guarantees that the event is fired before the rendered is killed if it just keeps allocating memory? If so, the amount of available memory could be artificially reduced in a test environment, and the test could allocate 100 MB at a time until the event is fired.

If you find that there is a kind of test for web exposed behavior that you'd like to write but it can't be done in web-platform-tests, please let me know.

[Mounir Lamouri]

On Mon, 17 Apr 2017, at 00:56, Philip Jägenstedt wrote:
> Should there be any guarantees that the event is fired before the
> rendered
> is killed if it just keeps allocating memory?

If based on system events, it might be hard to have such guarantee as it
would require the underlying platform to also have a similar guarantee.

-- Mounir