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.
