[whatwg] Low Memory Event

[Glenn Maynard]

On Sat, Jan 1, 2011 at 5:04 PM, Charles Pritchard <chuck at jumis.com> wrote:
> The separation of Mobile and Desktop seems arbitrary, in terms of specs:
> if it's useful on the mobile, why would it not be useful on the desktop?
>
> It's the same concept, a memory warning.

I fully agree that no HTML spec should make a distinction in any way
between mobile and desktop.  It's an impossible distinction to
maintain from a spec perspective, as it's hopelessly blurry--mobile
phones having higher and higher specs, iPads straddling the line in
the middle, netbooks pushing in from the other direction, and the
whole industry being a rapidly moving target that no spec will keep up
with.  I believe there are differences in practice that make low
memory events not very useful on desktops, but that decision should be
left to browsers.

>> 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
swapped to disk.  By accessing all of that data (there must be a lot
of it, for it to be worth serializing to disk), you've just forced the
OS to swap it all back into memory.  It also forced it to swap
something else out (probably Photoshop, which I'm trying to use) to
make space for it.  Serializing the data may use even more memory.
This has all just seriously aggrevated the memory condition.

Yet, doing that might be a perfectly valid response on a mobile
system, where no swap is involved in a low memory condition.  (Not
entirely accurate--some Android systems compress memory as a swap
mechanism.)  If applications aren't given enough information to
reasonably decide what to do, they'll have a single, universal
response which will be correct in some cases and probably incorrect in
many others.  (Or, they'll have to try to infer what it means based on
the browser and platform, which seems to defeat the purpose of
speccing it.)

-- 
Glenn Maynard