- From: Charles Pritchard <chuck@jumis.com>
- Date: Sat, 01 Jan 2011 16:44:15 -0800
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