W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] Low Memory Event

From: Charles Pritchard <chuck@jumis.com>
Date: Sat, 01 Jan 2011 16:44:15 -0800
Message-ID: <4D1FCA5F.3080607@jumis.com>
On 1/1/2011 4:07 PM, Glenn Maynard wrote:

>>> For example, responding to being an idle tab by releasing resources is
>>> the wrong thing to do if there's plenty of memory available.  I have 8
>>> GB of memory and Firefox rarely uses more than 512 MB.  Don't make me
>> I stated, in the example, that it would need more logic to function
>> appropriately.
> My point was that the event needs to give enough information to
> *allow* the application's logic to do this correctly.
>
>> They all have the same related meaning: get rid of unnecessary buffers,
>> serialize and save to disk, if appropriate.
>>
>> If I had a lowmemory event on the desktop, I'd run it through the exact same
>> logic I would on mobile.
> It just seems easy for this to go badly wrong.
>
> For example, suppose an implementation sends lowmemory when the system
> is low on swap; that is, it's actually running out of virtual memory
> entirely, and allocations are about to start failing or applications
> OOM-killed.  So, I'm in Photoshop using a lot of memory, stuff gets
> swapped out, and then when it's nearly out of memory, Firefox notices
> and broadcasts lowmemory.
>
> What happens then?  Your application decides to serialize its data and
> write it to disk, like you say.  But your application is already

Serialization mechanisms have to be pretty quick regardless:
otherwise you end up with poor behavior ("freezing gui") onunload.

You're usually moving less than 5 megs of data, when serializing to 
local storage,
as that's what localStorage is limited to in most environments.

Serializing isn't the primary use case: de-referencing unneeded objects 
is the primary reason
for the event. Serializing can help, of course.
Received on Saturday, 1 January 2011 16:44:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC