1124223 - implement performance.memory

Status: NEW

(Core :: DOM: Core & HTML, task, P5)

Description

[(not reading bugmail) Nick Desaulniers [:\n]]

looks like Chrome is getting a neat new API `performance.memory`.
https://github.com/paulirish/memory-stats.js#memory-statsjs

Comment 1

[Boris Zbarsky [:bzbarsky]]

"performance" is a standardized object.  Is there a spec for this?

Comment 3

[Tatsuto Horibe]

This is stingray blocker issue.
see below comment.
https://bugzilla.mozilla.org/show_bug.cgi?id=1132852#c0

Comment 4

[Boris Zbarsky [:bzbarsky]]

What exactly is the partner looking for?

The definition of "JS object" and "JS heap" differs in different engines; there are multiple different numbers that could be considered the used/totalJSHeapSize in Gecko + SpiderMonkey.  That's not to mention the fact that some parts of the JS heap are shared across origins, so providing actual information about the state of the JS heap would be a cross-origin information leak, while limiting the reporting to the unshared parts of the heap obviously means reporting numbers that have limited bearing on reality.

Is the partner looking for actual useful information (and if so, what sort of information), or are they just playing buzzword-bingo games with requirements?  Because if it's the latter we can clearly just make up something and report something, but it it's the former then we need to understand what information they're actually looking for.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I guess the real question is what the "service vendor" mentioned in bug 1132852 comment 0 is looking for.  Sorry I didn't make that clearer.

Comment 6

[Tatsuto Horibe]

We are asking the detail requirement of this function to the partner (service vender).
But from other requirement,
- The target device SHOULD have 150 megabytes of memory available to the browser instance running the application.
- support Media Source Extensions [1]
I guess this function is used to manage the amount of Media Source Buffer.

[1] http://w3c.github.io/media-source/

Comment 7

[Emanuel Hoogeveen [:ehoogeveen]]

I'm implementing per-compartment memory counters in bug 1123434, fwiw, though they will have all the caveats that bz mentioned (there are various alloc types that cannot be associated with a single compartment, and associated malloc memory usage is not covered, only the GC heap). I also need to address performance concerns before they can hope to land.

But it sounds like the feature you're requesting might be something entirely different and unrelated. Do you actually want performance.memory to give the amount of memory *remaining on the device*?

Comment 8

[Tatsuto Horibe]

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #7)
> But it sounds like the feature you're requesting might be something entirely
> different and unrelated. Do you actually want performance.memory to give the
> amount of memory *remaining on the device*?

No, *remaining on the device* is too big and we cannot accept to use almost memory for one application.
performance.memory.totalJSHeapSize may be determined by preference, acceptable value for each device.

Thanks

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Are we dealing with separate child processes here? Since performance.memory (whatever it would be measuring) could be naturally more accurate if it deals with only one web app running in a child process.

Comment 10

[Boris Zbarsky [:bzbarsky]]

OK, I'm going to reopen bug 1132852 and resummarize it, because it doesn't sound like what we want here is used/totalJSHeapSize at all, and it also sounds like what we want might not in fact match any web-facing API....  Let's move the discussion about the stingray requirements back to bug 1132852.

Comment 11

[Andrew McCreight [:mccr8]]

Chrome has been shipping some kind of client-visible memory API since at least 2012.  They wrote a blog post about it:
  http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/

For me, the exciting part is the graph in the section "Resolving Gmail's Memory Crisis".  They are able to monitor their application, server-side, for memory usage.  The data is even sensitive enough to detect a fragmentation-related GC regressions in Chrome.

The measurement is quantize into coarse buckets (in terms of both time and space I assume) to reduce the security risk.  I don't know how they deal with cross-origin information.  I believe they don't have compartments, so maybe they just expose the memory used by a tab's process?  If you search for "chrome performance.memory quantize" then you'll see some related discussion.

Comment 12

[Andrew McCreight [:mccr8]]

In terms of a spec, in the Chrome bug for adding performance.memory to workers ( https://code.google.com/p/chromium/issues/detail?id=326370 ) somebody said on Dec 1 2014, "The discussion resulted that a spec draft that hosted someware is a need, unfortunately, it is not convenient for me to draft and host it :( , so sorry about that." so I'm guessing there's no spec.

There is this bit of documentation:
  https://docs.webplatform.org/wiki/apis/timing/properties/memory

Beyond that, we probably need to read code to figure out what exactly they are doing.

Comment 13

[Paul Irish]

Hiyo,

Shipping perf.memory for workers was blocked in blink-dev because it's spec-less.
https://groups.google.com/a/chromium.org/d/topic/blink-dev/g5YRCGpC9vs/discussion

Developers get a lot of value from this API, as seen in the activity and interest in https://github.com/paulirish/memory-stats.js. However, I (and others) haven't been able to develop a spec for the feature yet.

Meanwhile, the API isn't totally satisfactory to our customers. Apps like GMail/Drive want detail on total  (native) memory beyond just the JS Heap. I encourage the conversation in Issue 1132852 as the API we shipped in Chrome isn't satisfactory yet.

Comment 14

[(not reading bugmail) Nick Desaulniers [:\n]]

> Apps like GMail/Drive want detail on total  (native) memory beyond just the JS Heap.

This is a very important point.  When we started shipping 128 MB devices, I pointed out that not only does a dev have to be mindful of their peak JS Heap Size, but things like bitmaps, audio, video, and probably even complexity of the DOM affect total memory usage.

Comment 15

[Andrew McCreight [:mccr8]]

There is some detailed discussion of this API in the Google Doc linked from this post:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/g5YRCGpC9vs/b4OJz71NmPwJ

Comment 16

[Andrew McCreight [:mccr8]]

new proposal to change the behavior of this API in Chrome:
  https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/no00RdMnGio/hA9SZ3kmBAAJ

Comment 18

[Jukka Jylänki]

Hey, it would be great if this API was implemented to Firefox, perhaps just behind a pref if there are concerns. That would make it possible in CI environments to add tracking for memory usage.

Currently at Unity we have a need to be able to (cooperatively via JS code) unload and reload JS content dynamically while a page is running, and are running tests where we repeatedly reload the content to ensure we do not leak anything behind, but properly detach everything from old instance and loaded memory, before reloading.

We can run such reload CI tests only on Chrome at the moment. If performance.memory was available on Firefox (even behind a pref), we could run the reload stress tests also on Firefox on our CI servers.

Comment 19

[Panos Astithas (he/him) [:past] (please ni?)]

This API is no longer being pursued by Chrome for standardization:
https://github.com/mozilla/standards-positions/issues/85#issuecomment-426382208

We do have the relatively unknown performance.mozMemory API that may be useful to your usecase:
https://searchfox.org/mozilla-central/search?q=mozMemory&case=true&path=

Comment 20

[Raphaël Droz]

https://bugzilla.mozilla.org/show_bug.cgi?id=1125412 added performance.mozMemory.gc (behind thedom.enable_memory_stats` flag) 6 years ago.

But it contains nothing similar to totalJSHeapSize which is a metric developers are likely interested in.

I'm e2e-testing an app (which process big data streams) and want to ensure it's suitable to low-memory configurations.
Having the ability to check the heap before/after running some tests (and consequently spot performance regressions) would be incredibly useful.

Comment 21

[Raphaël Droz]

Fetching the maxHeapSize between two PerformanceMarks would be an even greatest metric.