[whatwg] Low Memory Event

[Rob Evans]

I think one of the most useful things that a js script could know is how
much memory is available and how much the current page is using. I'm writing
a js game engine and knowing how much I can safely site in memory would be
incredibly useful!

That way I can do everything to maximize engine performance. I could
determine how large I could make a canvas element, how much data I can store
client side in arrays or if need be, switch to asking the server for data
more often and storing less client side.

In a business use case, our company sends lots of data to the client to make
the user interface as responsive as possible rather than having to wait for
a server response to every query, but if the client doesn't have the memory,
we could switch to more server calls and less storage.

The use is valid and very helpful.

On 27 Sep 2010 23:19, "timeless" <timeless at gmail.com> wrote:

what exactly do you intend to do if you get such a signal?

In general, this is mostly a user problem. There are two basic cases:
1. user has one constrained device with one browser accessing a single
web site (yours) with no other open applications.
2. user has a device with multiple open windows (various sites,
various applications).

Let's first review the state of desktop browsers:
* Today, Google Chrome's task manager will tell a user how much memory
a web application is using (generally iiuc tabs for a single domain
share share a content process) and it even tries to show such details
for other browsers -- you can also watch memory by process in the
system task manager if you like.
* Mozilla has plans to provide something similar (in the interim, you
can use the system task manager, same general caveats).
* IE as of a few years ago has per process windows*(if you enabled
them or accidentally triggered them) and after that per process tabs
**(i don't know if they follow the same domain magic), memory usage
can be tracked in the standard task manager (taskmgr.exe or
procexp.exe if that replaced it or whatever).
* Safari is probably similar to IE / Mozilla in that you could use the
standard OS tools if you wanted to.
* I'm not sure about Opera, but it's probably the same (perhaps it has
something?).

Now, let's consider mobile operating "platforms":
* From memory, PalmOS and Windows Mobile had resource meters.
* Until recently iOS didn't expose multitasking to end users, so
instead apps merely showed users errors or disappeared.
* Maemo (disclaimer, I used to work here - we now work on MeeGo)
doesn't ship with a GUI resource manager. It does ship with "top"
('usable' *cough* from "X Terminal"). Like palm/windows mobile/iOS
users typically get an incomprehensible error. The UI design is
supposed to list "windows" err "applications" the user could choose to
close (no resource usage hints) -- and triggering this in Maemo 5 is
hard because marketting demanded we enable swap, so instead you swap
to death.
* I can't speak for Moblin/MeeGo or Android.
* Symbian! This awesome platform gives an incomprehensible warning and
then kills a random application. The warning like Maemo's tries to
encourage the user to randomly kill an app from the app switcher
(which like Maemo has no resource hinting, but unlike Maemo doesn't
even give window titles, just app names. and in general this doesn't
work -- perhaps apps tend to be in kernel space waiting for memory
when inactive?)
* The specification for the Sugar UI (from OLPC) was to show users a
donut describing memory use per window. When the donut is full,
obviously there isn't room for additional windows. The user can also
identify an expensive portion of the donut and choose to discard it.
Since the size of each arc is proportional to the memory used by the
window, the user is able to make intelligent choices and understand
consequences. -- Sadly, afaik this was never implemented.

How do web applications handle this problem today?
Gmail has 3 major ui's for browsers:
/?ui=2 (+/- chat, +/- buzz, +/- personalized inbox)
/?ui=1 (basic js-- this is going to die soon)
/h/ (html only)

By default you connect, and google sets some timeouts (I haven't
checked the impl details, but I think I've hit a bunch of the major
edge cases):
- If you don't have js enabled, I think a meta redirect will fire
sending you to /h/ (or perhaps they use noscript).
- Some timer will trigger if ui=2 "takes too long to load", it will
offer ui=1 or /h/.

As long as the http level redirect timeout isn't lost because of oom
(I've never had this problem), the fallback works.


The reality is that users will either reload your page (or restarts
their browser/computer -- don't laugh, I watched a kid press the power
key on the computer he was using when the Flash app didn't work
properly this Saturday night -- the network was flaky at the time) or
go elsewhere. Your server's application logic needs to detect the case
where the user does this, just as Windows would try to tell the kid
that the computer wasn't shut off properly and as Google tells me that
Gmail is loading slowly. (To be fair to the kid, when I was barely
older than him, that was roughly how I shut down OS/2, I didn't know
better - I assumed the DOS prompt I saw meant it was safe).

Catastrophic handling:
* In Maemo 5, because of the configurations described above, the
reality is that while there are low memory signals available, they
aren't sent. Instead, applications are killed by the oom-killer.
During development, there was a time when the only app that could be
killed was one which would be respawned if it died --  this was
hillariously depressing. People are encouraged to expect to be killed
and instead ensure that any important state be saved somewhat eagerly
(definitely don't wait for the user to click "save"). If the app
starts again later and discovers an incomplete state, it should
resume. This also covers the unfortunate case where someone pulls
their battery out or runs it dry (mine has been run dry a number of
times during *this* vacation, usually because I'm trying to
continually track GPS position for a full day excursion).
* The default Linux overcommit policy makes allocating memory in a
multitasking platform (like Maemo) more exciting in that someone
(anyone) else can spend the memory you wanted for your allocation
between when you look and when you leap. Thus while it makes sense to
check for very large allocations where you'd like to fail, it's
impratical for others -- even malloc() on Linux doesn't ensure safety
-- the kernel will be forced to kill() you if it discovers it can't
map memory it promised to you (and can't free memory by killing
someone else).
* While I haven't read the iOS spec, the design behind iOS 3 and
earlier is similar to classic Palm in that switching away from a
running app means it isn't running, and since pressing the home button
triggers this, everyone designs for it. I went into an Apple store in
Belfast last week and played some trial game. I pressed the home
button a couple of times because I thought staff was closing up. When
I realized I had more time, I just reopened the game and continued.
* The design for Gecko content** processes is such that when we run
out of memory, we're going to kill ourselves (and you with us). We
might respawn the content process (automatically or after user
intervention). We will *not* (at least today) restore dom state or js
state. I suspect this is the design that Chrome, Opera, Safari and IE
will all take. In Gecko you'll probably see a "this is embarassing"
page (at least in the near future until the UX team designs something
better) -- during this trip, the people I spoke with recalled it
fondly.

**Note: the Gecko chrome process isn't actually different, but
eventually we hope it won't allocate much memory so it shouldn't be as
likely to crash/be killed.

I haven't covered the dedicated platform case (point 1 from the top)
beyond noting that iOS3-/Palm/Symbian/S40 have it with an experience
of "oops" and an expectation of state saving. If you know an awful lot
about the platform, you can try to custom tailor yourself to it. I
don't think that's practical for web apps (it doesn't seem to work for
native apps - why should we trust you to do better?). The web is about
dynamic tuning. Try something, if it works, good, if it doesn't or
takes too long, do something else. You can unfortunately try to
estimate memory space, JS and DOM will both throw exceptions if you
ask for too much. But more importantly: the user will complain in some
way if you take too long. Learn from the boy w/ the Flash app and from
Gmail's login page: if something takes too long, you user is going to
kick you and/or leave. Instead of expecting the browser to give you a
low memory hint, recognize when using memory slows down processing
(remember it's likely to slow down if allocating memory involves
swapping). If you are doing 20fps and you suddenly fall to 5fps,
either you've used too much, or the user has effectively split
resources to another task. Either way: you should reduce your resource
usage (memory, processing time).

You can consider negotiating with the user, but please remember that
Adove Flash's rendering context menu (High, Medium, Low anyone?) was
an utter failure (undiscoverable, virtually useless - it only affects
vector animation, not video/cpu, nor sprites). Gmail has links to
Html/Mobile at the bottom, I doubt we could get them to disclose usage
info, but I think it's safe to say they found them valuable enough
(for users' satisfaction) to include (Google seems to test/validate
just about everything).

Also, your user often has a choice of providers, that kid and myself
can and will go elsewhere if we're mistreated. Two news providers
mistreated me before I finished writing this email, I'll now try to
remember not to use them (it'll take the kid a bit to learn to switch,
but there was a Wii available and it was used). Please do not assume
that my battery operated device is soley for your use***. If you run
my battery down and I can't make a phone call or use GPS later, I will
(eventually) learn to avoid you.

-- Written in Opera 10.1 for the n900 over the course of a day
(breakfast, dinner) w/ gmail /h/ (no spell checker), please forgive me
for any typos.

*** On the subject of task managers, I hope that in the future we're
able to show users how much battery a given web site/property (or
standalone application) spent/wasted per unit time. It would help
users understand why their phone ran out of power that day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100927/2890de24/attachment-0002.htm>