<p>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!</p>

<p>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.</p>

<p>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.</p>

<p>The use is valid and very helpful.</p>
<p><blockquote type="cite">On 27 Sep 2010 23:19, "timeless" <<a href="mailto:timeless@gmail.com">timeless@gmail.com</a>> wrote:<br><br>what exactly do you intend to do if you get such a signal?<br>
<br>
In general, this is mostly a user problem. There are two basic cases:<br>
1. user has one constrained device with one browser accessing a single<br>
web site (yours) with no other open applications.<br>
2. user has a device with multiple open windows (various sites,<br>
various applications).<br>
<br>
Let's first review the state of desktop browsers:<br>
* Today, Google Chrome's task manager will tell a user how much memory<br>
a web application is using (generally iiuc tabs for a single domain<br>
share share a content process) and it even tries to show such details<br>
for other browsers -- you can also watch memory by process in the<br>
system task manager if you like.<br>
* Mozilla has plans to provide something similar (in the interim, you<br>
can use the system task manager, same general caveats).<br>
* IE as of a few years ago has per process windows*(if you enabled<br>
them or accidentally triggered them) and after that per process tabs<br>
**(i don't know if they follow the same domain magic), memory usage<br>
can be tracked in the standard task manager (taskmgr.exe or<br>
procexp.exe if that replaced it or whatever).<br>
* Safari is probably similar to IE / Mozilla in that you could use the<br>
standard OS tools if you wanted to.<br>
* I'm not sure about Opera, but it's probably the same (perhaps it has<br>
something?).<br>
<br>
Now, let's consider mobile operating "platforms":<br>
* From memory, PalmOS and Windows Mobile had resource meters.<br>
* Until recently iOS didn't expose multitasking to end users, so<br>
instead apps merely showed users errors or disappeared.<br>
* Maemo (disclaimer, I used to work here - we now work on MeeGo)<br>
doesn't ship with a GUI resource manager. It does ship with "top"<br>
('usable' *cough* from "X Terminal"). Like palm/windows mobile/iOS<br>
users typically get an incomprehensible error. The UI design is<br>
supposed to list "windows" err "applications" the user could choose to<br>
close (no resource usage hints) -- and triggering this in Maemo 5 is<br>
hard because marketting demanded we enable swap, so instead you swap<br>
to death.<br>
* I can't speak for Moblin/MeeGo or Android.<br>
* Symbian! This awesome platform gives an incomprehensible warning and<br>
then kills a random application. The warning like Maemo's tries to<br>
encourage the user to randomly kill an app from the app switcher<br>
(which like Maemo has no resource hinting, but unlike Maemo doesn't<br>
even give window titles, just app names. and in general this doesn't<br>
work -- perhaps apps tend to be in kernel space waiting for memory<br>
when inactive?)<br>
* The specification for the Sugar UI (from OLPC) was to show users a<br>
donut describing memory use per window. When the donut is full,<br>
obviously there isn't room for additional windows. The user can also<br>
identify an expensive portion of the donut and choose to discard it.<br>
Since the size of each arc is proportional to the memory used by the<br>
window, the user is able to make intelligent choices and understand<br>
consequences. -- Sadly, afaik this was never implemented.<br>
<br>
How do web applications handle this problem today?<br>
Gmail has 3 major ui's for browsers:<br>
/?ui=2 (+/- chat, +/- buzz, +/- personalized inbox)<br>
/?ui=1 (basic js-- this is going to die soon)<br>
/h/ (html only)<br>
<br>
By default you connect, and google sets some timeouts (I haven't<br>
checked the impl details, but I think I've hit a bunch of the major<br>
edge cases):<br>
- If you don't have js enabled, I think a meta redirect will fire<br>
sending you to /h/ (or perhaps they use noscript).<br>
- Some timer will trigger if ui=2 "takes too long to load", it will<br>
offer ui=1 or /h/.<br>
<br>
As long as the http level redirect timeout isn't lost because of oom<br>
(I've never had this problem), the fallback works.<br>
<br>
<br>
The reality is that users will either reload your page (or restarts<br>
their browser/computer -- don't laugh, I watched a kid press the power<br>
key on the computer he was using when the Flash app didn't work<br>
properly this Saturday night -- the network was flaky at the time) or<br>
go elsewhere. Your server's application logic needs to detect the case<br>
where the user does this, just as Windows would try to tell the kid<br>
that the computer wasn't shut off properly and as Google tells me that<br>
Gmail is loading slowly. (To be fair to the kid, when I was barely<br>
older than him, that was roughly how I shut down OS/2, I didn't know<br>
better - I assumed the DOS prompt I saw meant it was safe).<br>
<br>
Catastrophic handling:<br>
* In Maemo 5, because of the configurations described above, the<br>
reality is that while there are low memory signals available, they<br>
aren't sent. Instead, applications are killed by the oom-killer.<br>
During development, there was a time when the only app that could be<br>
killed was one which would be respawned if it died --  this was<br>
hillariously depressing. People are encouraged to expect to be killed<br>
and instead ensure that any important state be saved somewhat eagerly<br>
(definitely don't wait for the user to click "save"). If the app<br>
starts again later and discovers an incomplete state, it should<br>
resume. This also covers the unfortunate case where someone pulls<br>
their battery out or runs it dry (mine has been run dry a number of<br>
times during *this* vacation, usually because I'm trying to<br>
continually track GPS position for a full day excursion).<br>
* The default Linux overcommit policy makes allocating memory in a<br>
multitasking platform (like Maemo) more exciting in that someone<br>
(anyone) else can spend the memory you wanted for your allocation<br>
between when you look and when you leap. Thus while it makes sense to<br>
check for very large allocations where you'd like to fail, it's<br>
impratical for others -- even malloc() on Linux doesn't ensure safety<br>
-- the kernel will be forced to kill() you if it discovers it can't<br>
map memory it promised to you (and can't free memory by killing<br>
someone else).<br>
* While I haven't read the iOS spec, the design behind iOS 3 and<br>
earlier is similar to classic Palm in that switching away from a<br>
running app means it isn't running, and since pressing the home button<br>
triggers this, everyone designs for it. I went into an Apple store in<br>
Belfast last week and played some trial game. I pressed the home<br>
button a couple of times because I thought staff was closing up. When<br>
I realized I had more time, I just reopened the game and continued.<br>
* The design for Gecko content** processes is such that when we run<br>
out of memory, we're going to kill ourselves (and you with us). We<br>
might respawn the content process (automatically or after user<br>
intervention). We will *not* (at least today) restore dom state or js<br>
state. I suspect this is the design that Chrome, Opera, Safari and IE<br>
will all take. In Gecko you'll probably see a "this is embarassing"<br>
page (at least in the near future until the UX team designs something<br>
better) -- during this trip, the people I spoke with recalled it<br>
fondly.<br>
<br>
**Note: the Gecko chrome process isn't actually different, but<br>
eventually we hope it won't allocate much memory so it shouldn't be as<br>
likely to crash/be killed.<br>
<br>
I haven't covered the dedicated platform case (point 1 from the top)<br>
beyond noting that iOS3-/Palm/Symbian/S40 have it with an experience<br>
of "oops" and an expectation of state saving. If you know an awful lot<br>
about the platform, you can try to custom tailor yourself to it. I<br>
don't think that's practical for web apps (it doesn't seem to work for<br>
native apps - why should we trust you to do better?). The web is about<br>
dynamic tuning. Try something, if it works, good, if it doesn't or<br>
takes too long, do something else. You can unfortunately try to<br>
estimate memory space, JS and DOM will both throw exceptions if you<br>
ask for too much. But more importantly: the user will complain in some<br>
way if you take too long. Learn from the boy w/ the Flash app and from<br>
Gmail's login page: if something takes too long, you user is going to<br>
kick you and/or leave. Instead of expecting the browser to give you a<br>
low memory hint, recognize when using memory slows down processing<br>
(remember it's likely to slow down if allocating memory involves<br>
swapping). If you are doing 20fps and you suddenly fall to 5fps,<br>
either you've used too much, or the user has effectively split<br>
resources to another task. Either way: you should reduce your resource<br>
usage (memory, processing time).<br>
<br>
You can consider negotiating with the user, but please remember that<br>
Adove Flash's rendering context menu (High, Medium, Low anyone?) was<br>
an utter failure (undiscoverable, virtually useless - it only affects<br>
vector animation, not video/cpu, nor sprites). Gmail has links to<br>
Html/Mobile at the bottom, I doubt we could get them to disclose usage<br>
info, but I think it's safe to say they found them valuable enough<br>
(for users' satisfaction) to include (Google seems to test/validate<br>
just about everything).<br>
<br>
Also, your user often has a choice of providers, that kid and myself<br>
can and will go elsewhere if we're mistreated. Two news providers<br>
mistreated me before I finished writing this email, I'll now try to<br>
remember not to use them (it'll take the kid a bit to learn to switch,<br>
but there was a Wii available and it was used). Please do not assume<br>
that my battery operated device is soley for your use***. If you run<br>
my battery down and I can't make a phone call or use GPS later, I will<br>
(eventually) learn to avoid you.<br>
<br>
-- Written in Opera 10.1 for the n900 over the course of a day<br>
(breakfast, dinner) w/ gmail /h/ (no spell checker), please forgive me<br>
for any typos.<br>
<br>
*** On the subject of task managers, I hope that in the future we're<br>
able to show users how much battery a given web site/property (or<br>
standalone application) spent/wasted per unit time. It would help<br>
users understand why their phone ran out of power that day.<br>
</blockquote></p>