[memory] Memory events (was: [battery] Alternative design proposal)

Hi Charles, All,

On 15.9.2011, at 19.34, ext Charles Pritchard wrote:

> On 9/15/2011 12:53 AM, Anssi Kostiainen wrote:
>> 
>> On 14.9.2011, at 17.20, ext Josh Soref wrote:
>> 
>>> Anssi: of note, battery percentages can vary wildly if someone is amusing and swaps battery sources, a system can easily go from 100% charged to 50% charged (insert an empty battery), or from 99% charged to 33% charged (insert an empty high capacity battery). For more fun, it could go from 40% charged (kinda low), to 15% charged (insert an empty high capacity battery while trying to give more power to the system). In each of these cases, the actual amount of time remaining for the system hasn't changed, but you're going to cause any application listening to a percentage to panic.
>> This use case justifies the existence of battery{low|critical|ok} events.
> 
> We could scale our use of Web Workers, and more aggressively flush our memory to localStorage/disk, without going into a panic
> or otherwise intruding on user experience.
> 
> I've asked for a similar API for memory events; the iPhone is especially sensitive to low memory issues. That proposal was turned down on similar grounds, of being too unstable.
> 
> We don't need a perfect solution, just hints. We can use timers, release memory blocks, and take different code paths based on system hints.
> It's something we do anyway.
> 
> This is something I expect will be useful for long running web apps, for compute/memory intensive/high resolution input.
> 
> For documents, and the other 99% of work that web authors do, it may not be relevant.

I agree we could use a similar(-ish) design for memory events. WebKit's Web Inspector already exposes used heap size in its Timeline view, and I believe other browsers' developer tools do something similar as well.

Such an API is not explicitly mentioned in the DAP WG's Charter, but I'd guess it could potentially fit in to this WG given we've done work around e.g. the System Information API which exposes somewhat similar information. Alternative -- and perhaps even better -- home for memory events could be the proposed Browser Testing and Tools WG:

  http://www.w3.org/2011/08/browser-testing-charter

... but that WG has not been bootstrapped yet. Does anyone know its status?

Anyway, if there's wider interest in pursuing this route I could draft a strawman and see how it goes from there. Or do you Charles already have a more concrete proposal in mind you'd like to share with us?

Others, how do you feel about this proposal in general?

-Anssi

Received on Wednesday, 28 September 2011 10:52:49 UTC