Re: [whatwg] Low Memory Event
Date: Sun, 02 Jan 2011 04:59:14 -0600 From: Boris Zbarsky
bzbar...@mit.edu On 1/1/11 6:53 PM, Charles Pritchard wrote:
ArrayBuffer and Canvas use contiguous memory segments. You don't need a
complex GC pass to let those ones go.
Yes, you do. You can't let go of the canvas buffer without letting go
of the canvas rendering contexts and canvas elements referencing it.
And those used to be referenced from JS, so the only way they can go
away is via a GC.
Similar for ArrayBuffer: the memory segment is owned by various
garbage-collected objects, and can't go away until they do.
With canvas, you can just set canvas.width = 1; to let the memory go,
without a complex GC.
canvas.width = 1 can be used to quickly release several megs of ram.
On that note, a method of invalidating ArrayBufferView and
CanvasPixelArray would be helpful in the future.
Maybe that's something we could talk about, as we discuss the
feasibility of responding to lowmemory events.
Here's a thread considering .close() as an invalidate method name:
http://www.khronos.org/webgl/public-mailing-list/archives/1009/msg00229.html
And here's a quick attempt at example, on my part:
el.onclick = function() {
imageData.close();
worker.postMessage(imageData);
// imageData.data[0] = 0; now throws INVALID_STATE_ERR from this thread
}
.close() signals to postMessage to use a pointer, instead of cloning the
object.
Re: [whatwg] Low Memory Event
On 1/2/11, Aryeh Gregor simetrical+...@gmail.com wrote: Moreover, who says you're using a browser that puts different tabs in different threads; that that browser would still work correctly if you suspend a single thread and leave the others running; and that you even know that it's possible to suspend processes? (Windows doesn't even give the option in its default GUIs, last I checked, although it's possible to do.) As the system's clearly capable of multi-tasking, I figured it managed tasks. I did misunderstand timeless' email and applied his argument to off-line gaming as well. I don't understand why a server would rather waste resources on you if you're just flipping away for a bit, but sending and receiving noop packets to and from the server, than if you simply flip away?
Re: [whatwg] Low Memory Event
On 1/1/11 6:53 PM, Charles Pritchard wrote: ArrayBuffer and Canvas use contiguous memory segments. You don't need a complex GC pass to let those ones go. Yes, you do. You can't let go of the canvas buffer without letting go of the canvas rendering contexts and canvas elements referencing it. And those used to be referenced from JS, so the only way they can go away is via a GC. Similar for ArrayBuffer: the memory segment is owned by various garbage-collected objects, and can't go away until they do. -Boris
Re: [whatwg] Low Memory Event
On 1/1/11 2:39 PM, Charles Pritchard wrote: lowmemory does not need to mean that the OS is experiencing a low memory condition. Uh... then what does it need to mean? Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. Why would that make sense? If we're _actually_ in a low-memory condition that will unnecessarily page in that tab. If we're not, why do we want it to drop resources? The example requires no OS mem-warnings and would allow use cases such as mine, to clean up a little, when lowmemory is fired. I think you're focusing too much on your specific use case here, honestly, and not thinking through how this would work in general. -Boris
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 11:17 PM, Bjartur Thorlacius svartma...@gmail.com wrote: On 12/31/10, Ian Hickson i...@hixie.ch wrote: Please don't use all my memory for your Web-based game. :-) I may just be running it in the background while finding a video to watch, for example, in which case I really don't want the game using all my resources. Why would you want to run a game in the background? Is it an aural game? It could be a MUDD[1] where you're set to follow as part of a mob. It could be an IDLE RPG[2] The game could be paused but might terminate your session if it doesn't remain connected. A game which causes you to go back to a respawn point on start can be very frustrating if you're just flipping away for a bit. [1] http://en.wikipedia.org/wiki/Multi_User_Dungeons_and_Dragons_%28MUDD%29 [2] http://idlerpg.net/
Re: [whatwg] Low Memory Event
On 1/2/11, timeless timel...@gmail.com wrote: On Sat, Jan 1, 2011 at 11:17 PM, Bjartur Thorlacius svartma...@gmail.com wrote: On 12/31/10, Ian Hickson i...@hixie.ch wrote: Please don't use all my memory for your Web-based game. :-) I may just be running it in the background while finding a video to watch, for example, in which case I really don't want the game using all my resources. Why would you want to run a game in the background? Is it an aural game? It could be a MUDD[1] where you're set to follow as part of a mob. It could be an IDLE RPG[2] As for IDLE, wouldn't this be considered cheating? You're doing something other than idling, after all. The game could be paused but might terminate your session if it doesn't remain connected. Ok. A game which causes you to go back to a respawn point on start can be very frustrating if you're just flipping away for a bit. Why wouldn't you suspend the process (i.e. put it to sleep by stopping it).
Re: [whatwg] Low Memory Event
On Sun, Jan 2, 2011 at 7:41 PM, Bjartur Thorlacius svartma...@gmail.com wrote: Why wouldn't you suspend the process (i.e. put it to sleep by stopping it). because the server may kill you when the network socket times out or breaks. why should it waste resources on a non responsive client?
Re: [whatwg] Low Memory Event
On Sun, Jan 2, 2011 at 4:27 PM, timeless timel...@gmail.com wrote: On Sun, Jan 2, 2011 at 7:41 PM, Bjartur Thorlacius svartma...@gmail.com wrote: Why wouldn't you suspend the process (i.e. put it to sleep by stopping it). because the server may kill you when the network socket times out or breaks. why should it waste resources on a non responsive client? Moreover, who says you're using a browser that puts different tabs in different threads; that that browser would still work correctly if you suspend a single thread and leave the others running; and that you even know that it's possible to suspend processes? (Windows doesn't even give the option in its default GUIs, last I checked, although it's possible to do.)
Re: [whatwg] Low Memory Event
On 1/1/2011 12:08 PM, whatwg-requ...@lists.whatwg.org wrote: Date: Fri, 31 Dec 2010 22:01:42 -0600 From: Boris Zbarsky bzbar...@mit.edu On 12/31/10 7:35 PM, Charles Pritchard wrote: If I were to receive an event, letting me know a low memory condition exists There are various ways to try to work around this by trying to pre-reserve a memory pool, but they're not very reliable. I suggest ... get deallocated until garbage collection happens. Garbage collection can require memory to perform. In the case of Gecko, collecting ... So by the time you're out of memory, doing this is too late. It won't work. ... And significantly greater implementation complexity for browsers if they try to make it work. And it still wouldn't work. ... Then get desktop OS vendors to give applications a way to detect low memory reliably. Implementation details would not be defined by the spec. Implementation fo the event type would be low-cost, backward compatible, and a simple entry to existing spec docs. lowmemory does not need to mean that the OS is experiencing a low memory condition. Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) The example requires no OS mem-warnings and would allow use cases such as mine, to clean up a little, when lowmemory is fired. Mobile implementation: Mobile operating systems have lowmemory warnings, they are important for the durability of web apps running in mobile browsers. Expensive implementation: My mail client and web clients often compete with each other for memory: Mozilla apps drop image icons, WebKit crashes tabs. After a few tabs are crashed, or a few icons are dropped, they could certainly send a lowmemory event to remaining listeners. -Charles
Re: [whatwg] Low Memory Event
On 12/31/10, Ian Hickson i...@hixie.ch wrote: Please don't use all my memory for your Web-based game. :-) I may just be running it in the background while finding a video to watch, for example, in which case I really don't want the game using all my resources. Why would you want to run a game in the background? Is it an aural game?
Re: [whatwg] Low Memory Event
I'd like to be able to listen for them on the desktop as well. You need to know a lot about the host system to know what low memory even means. Does it mean allocations may start failing soon? Does it mean we're deep into swap, causing serious performance issues but not failed allocations? Even that's hard to define; you can be using a lot of swap, but it may be for entirely unused, idle background applications and not indicate memory pressure at all. This definitely seems useful on mobile platforms, where memory is much more limited, memory management is much less complex, and being able to deal reliably with memory limitations is a much more pressing issue. But on desktop platforms, even native applications written for a specific platform run into trouble when they try to respond intelligently to memory pressure, and the vast majority don't try. On Sat, Jan 1, 2011 at 3:39 PM, Charles Pritchard ch...@jumis.com wrote: Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) An event like this needs to have a consistent meaning to allow applications to respond meaningfully. If it has varied meanings--or if it has attributes to indicate each meaning, but they don't get implemented in practice, or are too generic and don't accurately describe the situation on each platform and configuration--then applications can't respond correctly. 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 wait for resources to be reloaded (or re-cached, or whatever the resource is) because they were released just in case. I have lots of memory precisely because I don't want to wait; I want applications to cache as much as possible. (The tab visibility proposal seems more appropriate for this particular example, anyway.) I'm not saying this is impossible, but memory management is exceptionally complex, varies wildly across platforms, varies wildly depending on how much memory and swap a system has, and on the behavior of other applications on the system. I'd be concerned about a generic, loosely-defined lowmemory event with entirely unrelated meanings encouraging developers to respond to it in ways that only happen to make sense on the platform they're testing on. -- Glenn Maynard
Re: [whatwg] Low Memory Event
On 1/1/2011 1:43 PM, Glenn Maynard wrote: You need to know a lot about the host system to know what low memory even means. Does it mean allocations may start failing soon? Does it ... This definitely seems useful on mobile platforms, where memory is much more limited, memory management is much less complex, and being able to deal reliably with memory limitations is a much more pressing issue. But on desktop platforms, even native applications written for a specific platform run into trouble when they try to respond intelligently to memory pressure, and the vast majority don't try. I realize it's an exotic feature. 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. On Sat, Jan 1, 2011 at 3:39 PM, Charles Pritchardch...@jumis.com wrote: Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) An event like this needs to have a consistent meaning to allow applications to respond meaningfully. If it has varied meanings--or if it has attributes to indicate each meaning, but they don't get implemented in practice, or are too generic and don't accurately describe the situation on each platform and configuration--then applications can't respond correctly. It has a consistent meaning, again, though, we're talking about whether it's a semantic meaning or a technical one. The technical meaning, we can't allocate memory isn't something that can be used on every platform, per Boris' comments. The semantic meaning is pretty straightforward: low memory warning. It's really up to the author to decide what they want to do with a low memory warning, and up to the vendor to decide if they want to send one out. Anything else seems to be impractical. 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. It was just a simple example to demonstrate that memory can be released without OS support, and that applications could use that information. I'm not saying this is impossible, but memory management is exceptionally complex, varies wildly across platforms, varies wildly depending on how much memory and swap a system has, and on the behavior of other applications on the system. I'd be concerned about a generic, loosely-defined lowmemory event with entirely unrelated meanings encouraging developers to respond to it in ways that only happen to make sense on the platform they're testing on. 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. Without the generic lowmemory, we're just going to go on without the event (except in extensions), with visibility/focus the only tool to test with. -Charles
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 5:04 PM, Charles Pritchard ch...@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
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 2:04 PM, Charles Pritchard ch...@jumis.com wrote: It's the same concept, a memory warning. On Sat, Jan 1, 2011 at 3:39 PM, Charles Pritchardch...@jumis.com wrote: Here are some example implementations; it's up to the vendor, not the spec. Tabbed browsing implementation: Send a lowmemory event to hidden tabs listening (for lowmemory), that have not been visible for more than 60 seconds. (This is a partial example, as it doesn't detail when the tabs would be checked for visibility. ) An event like this needs to have a consistent meaning to allow applications to respond meaningfully. If it has varied meanings--or if it has attributes to indicate each meaning, but they don't get implemented in practice, or are too generic and don't accurately describe the situation on each platform and configuration--then applications can't respond correctly. It has a consistent meaning, again, though, we're talking about whether it's a semantic meaning or a technical one. The technical meaning, we can't allocate memory isn't something that can be used on every platform, per Boris' comments. The semantic meaning is pretty straightforward: low memory warning. It's really up to the author to decide what they want to do with a low memory warning, and up to the vendor to decide if they want to send one out. Anything else seems to be impractical. What I don't understand about this proposal is how web apps are supposed to free memory. In my understanding, ES5 doesn't allow you to manually free memory (unlike Objective-C), and it's up to GC implementor to decide how and when (most of) resources are freed. - Ryosuke
Re: [whatwg] Low Memory Event
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.
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 7:35 PM, Ryosuke Niwa rn...@webkit.org wrote: What I don't understand about this proposal is how web apps are supposed to free memory. In my understanding, ES5 doesn't allow you to manually free memory (unlike Objective-C), and it's up to GC implementor to decide how and when (most of) resources are freed. Freeing memory in the context of Javascript means make available to the collector to be freed, eg. drop references. Actually collecting any resulting objects as a result of that is up to the implementation: presumably a thorough GC pass would be forced after sending this message, to actually free memory that the application released. (That seems simple enough on mobile browsers, but on desktop systems doing such a collection pass might force everything to be paged back into memory, and to incorrectly hint the OS that everything is active and shouldn't be paged back out quickly, so it's probably not that simple in practice.) -- Glenn Maynard
Re: [whatwg] Low Memory Event
On 1/1/2011 4:48 PM, Glenn Maynard wrote: On Sat, Jan 1, 2011 at 7:35 PM, Ryosuke Niwarn...@webkit.org wrote: What I don't understand about this proposal is how web apps are supposed to free memory. In my understanding, ES5 doesn't allow you to manually free memory (unlike Objective-C), and it's up to GC implementor to decide how and when (most of) resources are freed. Freeing memory in the context of Javascript means make available to the collector to be freed, eg. drop references. Actually collecting any resulting objects as a result of that is up to the implementation: presumably a thorough GC pass would be forced after sending this message, to actually free memory that the application released. (That seems simple enough on mobile browsers, but on desktop systems doing such a collection pass might force everything to be paged back into memory, and to incorrectly hint the OS that everything is active and shouldn't be paged back out quickly, so it's probably not that simple in practice.) ArrayBuffer and Canvas use contiguous memory segments. You don't need a complex GC pass to let those ones go. For my use cases, those are the two types I'm working with. Keeping them around helps the speed of my app, letting them go cuts down on memory usage.
Re: [whatwg] Low Memory Event
On 1/1/2011 4:07 PM, Glenn Maynard wrote: On Sat, Jan 1, 2011 at 5:04 PM, Charles Pritchardch...@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. ... My point was that the event needs to give enough information to *allow* the application's logic to do this correctly. ... 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.) I'm perfectly fine if a desktop implementer decides that they are not going to send low memory events. For me, the purpose of getting the event in the specs is to promote its use, and ensure that the HTML spec for mobile and desktop stays in sync. It's clearly a useful event for mobile; even if desktop vendors decide not to fire events, it'd be good to see it in the specs.
Re: [whatwg] Low Memory Event
On Sun, 02 Jan 2011 00:53:48 -, Charles Pritchard ch...@jumis.com wrote: ArrayBuffer and Canvas use contiguous memory segments. You don't need a complex GC pass to let those ones go. For my use cases, those are the two types I'm working with. Keeping them around helps the speed of my app, letting them go cuts down on memory usage. Maybe better solution would be to add purgeable flag to canvas (i.e. allow browser to clear canvas at any time) or some way to create/mark weak references? (i.e. a reference to object that can be changed to null if browser is in low-memory situation). Although, I'm not convinced that handling of low memory in JS is necessary. Browsers already have some ways to free memory, e.g. by freeing all bitmaps for img or simply by unloading whole pages. Amount of available memory, even on mobile devices, increases dramatically each year. It's possible that by the time this feature gets specified, implemented, released and installed on significant number of devices it will be irrelevant. On my desktop computer I often have 100 tabs open and memory is not an issue, and my mobile phone has 1/16th of that RAM already. -- regards, Kornel Lesiński
Re: [whatwg] Low Memory Event
On 2011-01-02 03:27, Kornel Lesiński wrote: On Sun, 02 Jan 2011 00:53:48 -, Charles Pritchard ch...@jumis.com wrote: ArrayBuffer and Canvas use contiguous memory segments. You don't need a complex GC pass to let those ones go. For my use cases, those are the two types I'm working with. Keeping them around helps the speed of my app, letting them go cuts down on memory usage. Maybe better solution would be to add purgeable flag to canvas (i.e. allow browser to clear canvas at any time) or some way to create/mark weak references? (i.e. a reference to object that can be changed to null if browser is in low-memory situation). Although, I'm not convinced that handling of low memory in JS is necessary. Browsers already have some ways to free memory, e.g. by freeing all bitmaps for img or simply by unloading whole pages. Amount of available memory, even on mobile devices, increases dramatically each year. It's possible that by the time this feature gets specified, implemented, released and installed on significant number of devices it will be irrelevant. On my desktop computer I often have 100 tabs open and memory is not an issue, and my mobile phone has 1/16th of that RAM already. I think this is starting to get off topic, as we're now into OS memory allocation territory. If the browser is told by the OS or the browser feels it need to conserve memory it can do whatever it pleases, OS stability trumphs web page/app/script/whatever, and should always do so. Charles, you initially said you where worried about this since you used undo buffers. Why not simply add undo buffers to the Canvas spec? That way the browser can start tossing away the oldest undo buffers automatically when it starts getting memory anorexic. And depending on the browser implementation and the OS and hardware support, on some systems the Canvas undo buffers could even be in graphics memory. It's wrong for Canvas to have undo stuff in active memory, most graphics programs store the undo on disk or it's paged out to a swapfile at the least. So if you have to make your own undo buffers for Canvas, then I'd say that Canvas is lacking and might need undo buffers as part of it's spec. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Low Memory Event
On Sat, Jan 1, 2011 at 9:52 PM, Roger Hågensen resca...@emsai.net wrote: Charles, you initially said you where worried about this since you used undo buffers. Why not simply add undo buffers to the Canvas spec? That way the browser can start tossing away the oldest undo buffers automatically when it starts getting memory anorexic. And depending on the browser implementation and the OS and hardware support, on some systems the Canvas undo buffers could even be in graphics memory. It's wrong for Canvas to have undo stuff in active memory, most graphics programs store the undo on disk or it's paged out to a swapfile at the least. So if you have to make your own undo buffers for Canvas, then I'd say that Canvas is lacking and might need undo buffers as part of it's spec. Concepts like undo buffers are high level application behavior--that doesn't belong in Canvas directly. A discardable flag is the right level of abstraction, though. It's definitely not simple. It also would be needed in many separate APIs--Canvas, WebGL, ArrayBuffer, HTMLImageElement, and anything else that can store large blocks of data (directly or indirectly). I started suggesting the same thing, but stopped since I don't see that ever happening. For what it's worth, Windows used to have an API to allocate discardable memory, which could be deallocated under memory pressure; it required locking and unlocking the memory, so when unlocked the memory essentially operated as a weak reference that could be deallocated as needed. I think this was only supported in Win16 (the GMEM_DISCARDABLE flag to GlobalAlloc); I mention it only for reference. -- Glenn Maynard
Re: [whatwg] Low Memory Event
On 12/31/10 7:35 PM, Charles Pritchard wrote: If I were to receive an event, letting me know a low memory condition exists In many cases the only way a browser can determine that such a condition exists is by trying to allocate memory and having the allocation fail. At which point... it's out of memory. It doesn't have memory to allocate the event object, much less to run your script. There are various ways to try to work around this by trying to pre-reserve a memory pool, but they're not very reliable. I suggest reading the pretty extensive discussions on this topic in Mozilla's bugzilla and on the various Mozilla mailing lists over the last several years. I'd drop most of my buffers immediately, allowing for the machine and my application to carry on normally, a little while longer. drop most of my buffers means you stop referencing them. They don't get deallocated until garbage collection happens. Garbage collection can require memory to perform. In the case of Gecko, collecting canvases in fact requires a cycle-collection algorithm to run, which has to build a graph representing the current reference graph. It's a fairly memory-hungry algorithm. So by the time you're out of memory, doing this is too late. It won't work. The downside is that there'd be another word in the large vocabulary of HTML/DOM events. And significantly greater implementation complexity for browsers if they try to make it work. And it still wouldn't work. The usefulness has already been proven by iOS applications. We can work with low memory events there. iOS may well provide useful low memory notifications to applications. Other OSes do not. You find out about low memory when your allocation fails if you're lucky or when the kernel sends you a SIGKILL (Linux, I'm looking at you). I'd like to be able to listen for them on the desktop as well. Then get desktop OS vendors to give applications a way to detect low memory reliably. -Boris
Re: [whatwg] Low Memory Event
On Fri, 24 Sep 2010, Charles Pritchard wrote: Do we have a route, or DOM events that signal when the device has a low memory condition? My computer is constantly running low in memory. Mozilla-apps (thunderbird) start hiding unneeded icons; Chrome betas just go ahead and crash the active process. Mobile platforms all have such low memory hooks for their apps. They're necessary to allow designers to add additional logic to handle the condition by releasing buffers, serializing data, using localStorage, etc. For practical reasons, we can't really constrain user agents in situations related to hardware limitations. Different platforms have different ways of dealing with these situations and it's not always possible for a user agent to comply with specific requirements. (For example, when running out of memory, the UA might no longer be able to spin up the JS interpreter.) On Mon, 27 Sep 2010, Rob Evans wrote: 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. Please don't use all my memory for your Web-based game. :-) I may just be running it in the background while finding a video to watch, for example, in which case I really don't want the game using all my resources. Also, resources tend not to be as simple as the above could describe. For example, right now you could allocate 3 GB of RAM on this machine without any difficulty, you could allocate 6 GB if you're willing to wait for other apps to be paged out, and you could allocate 12 GB if you're willing to have your RAM be backed by a slower medium (like disk), thrashing like crazy. But that's right now; maybe while you're getting the 3 GB of data set up, some other app will allocate 20 GB and will evict you entirely out of the computer. And maybe when you create a 100-character string in one browser it actually takes just 100 bytes, but on another browser it might take 1000. So not only would the information be unreliable, it would be insufficient to really make good judgements. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Low Memory Event
Am 28.09.2010, 01:01 Uhr, schrieb timeless timel...@gmail.com: tl;dr of my previous post: it's impossible to know how much memory is available in the future. How much memory you're currently using is something that /could/ probably be provided in the near future. *However*, there might be a concern that this could be abused by attackers trying to figure out information about the host environment. Either way, you'll have to wait for browsers to finish exposing this to users before it becomes exposed to web applications. How about maybe a percentage of Javascript memory used? We could check if it goes into critical mass (95 %?) to reduce stored things. Browsers could enlarge said Javascript memory or make it smaller at will. As for canvas sizes... The amount of available ram can easily have nothing to do with video graphics surface restrictions. This is a distinct requirement (thanks for listing it). I think it's probably more reasonable for browsers to provide a hint about this than the others. Again there are security concerns, and resource race conditons. But if the number is clamped and can somehow float, perhaps it's workable. Keep in mind that there could be 5 windows side by side each competing to waste e.g. GL contexts on an overly constrained GL based system (the embeddings I'm looking at suck like this). That leaves the i want to dump data to cache case, which is covered by use a timer (even Date()) and figure out if things have slowed too much. For this case, you should in theory start by playing with localStorage and application-cache. This gives me an idea. How about if the browser exposed a hint for processor usage. Like low, medium, high in context of the Javascript Website. This means if the processor is at 80 % usage in the OS task manager, it could still be on low for the Javascript application depending on how much it currently uses. Which means if the Javascript application reaches high, it would certainly become unresponsive. Another example: The OS processor is at 98 %. the Javascript app uses only 1 % of it, but STILL goes medium or even high because it uses a lot of the currently available resources. At some point there should of course be a limit on how much of the processor it CAN use if it idles. Automatically tuning is your user's friend. And it doesn't require any new apis :) Virus checked by G DATA AntiVirus Version: AVB 21.366 from 27.09.2010 Virus news: www.antiviruslab.com
Re: [whatwg] Low Memory Event
On 9/28/10, Rob Evans r...@mtn-i.com wrote: All good points. I think as we have moved away from simple web pages and really start to think about applications that are coded in js, many things previously the exclusive domain of desktop apps are more and more desirable for web apps. Unfortunately, moving away from simple pages introduces pain points previously only experienced in desktop applications. Browser design should aim to avoid exposing such pain points. I also think that a web page should be able to request exclusive access to the graphics card just like many native games do, and that the user need not be aware that anything different has occurred because the browser can simply pause other processes that are not in focus. We implemented this for the browser in Maemo 5. It means that basically all Google applications break when you switch windows. Imagine trying to use Gmail only to discover it's broken. It was a terrible idea. It still *is* a terrible idea. Note that this was implemented by suspending JavaScript (in a bad way), not by suspending painting -- painting generally stops anyway when a window isn't visible. Gmail has a couple of features which need to work while backgrounded, one is new mail notifications (or updates to the live window), another is new chats/new chat messages. You wouldn't like not being able to get calls or sms's while playing a game, and mail/im is the same (which is why the Maemo presence system doesn't kill itself when you run an application...). Only an application knows what should be done when backgrounded. But some forms of backgrounding shouldn't really be exposed to apps. I don't want an interstitial page to recognize that I'm ignoring it -- sadly, the future is in this direction, interactive ads which block content views until they're dismissed. I realise the technical aspects of doing that are mega complex. For one, each process that is currently using the gpu would need to be signaled that it no longer has access at the moment and to pause itself, but then again, desktop apps have had to deal with these events for ages. Desktop apps and mobile apps (especially on Maemo) often don't pay attention to such details. They continue painting and doing work -- because the user doesn't care and didn't complain. On a desktop computer, with a power cable, background processes don't matter much, and to some extent users have learned to kill background tasks when things get sluggish. Before we introduce more web features, we need to find out if we can teach users similar things for web apps. People I spoke to yesterday (traveling is great) all had iOS3 devices and they understood that when one page was open everything else was dead (they didn't necessarily like it, one complained about Skype dying when switching to something else), they also understood that this doesn't happen on the desktop and didn't expect it to happen there. None of them really thought about how to manage such resources, but to some extent they had selected optiminal window/tab limits for themselves. It'd be nice to know if Safari on iOS3 sends events to pages when the user switches away and back, I've assumed it just saves a picture and reloads the page. It's been a while but I remember coding a similar event handler for when a user pressed the windows key and suddenly my game was minimised. If I remember correctly, I had to re-initialise direct x or open gl before I could continue processing. Part of using a web framework has involved shielding devs from that pain. However my understanding of the Linux/Maemo behavior w/ GLES2 is that one application has no ability to kick out other applications' surfaces (and some are used by compositors -- which are necessary). I do remember Windows applications getting blanked out when they lost focus, but this also matches GDI damage behavior and doesn't match classic HTML behavior (Canvas might be different here). Imagine a user loads 2 html-canvas3d games. Imagine that the system doesn't have much memory and that the user is paying for bandwidth (I'm in .ie w/ .uk and .fi sims -- I'm roaming, it's expensive). Is the user going to be happy with you trying to store your inactive game in DOM/JS (which causes swapping) and then with you trying to use the network as a storage? The right thing to do is to recognize your FPS has dropped to unusable, try decreasing the size of your surfaces, failing that, pause the game *yourself* and ask the user what to do. What will probably happen is *nothing* for a while - because the user was doing something else (playing the other game). Maybe the user just wanted you to load your resources and went to play tetris3d while waiting. Can't we have something similar on a browser with js events? As I tried to explain, they turned out to be incredibly unreliable/unusable for non browser applications (Maemo 5). At least on Maemo 5 the low memory events (which were at least sort of used in Maemo 4) are
Re: [whatwg] Low Memory Event
Totally agree. +1! -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Charles Pritchard Sent: 24 September 2010 21:57 To: whatwg@lists.whatwg.org Subject: [whatwg] Low Memory Event This is likely mentioned in the Device API specs, or somewhere around there at the W3C: Do we have a route, or DOM events that signal when the device has a low memory condition? My computer is constantly running low in memory. Mozilla-apps (thunderbird) start hiding unneeded icons; Chrome betas just go ahead and crash the active process. Mobile platforms all have such low memory hooks for their apps. They're necessary to allow designers to add additional logic to handle the condition by releasing buffers, serializing data, using localStorage, etc. -Charles
Re: [whatwg] Low Memory Event
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
Re: [whatwg] Low Memory Event
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 timel...@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
Re: [whatwg] Low Memory Event
tl;dr of my previous post: it's impossible to know how much memory is available in the future. How much memory you're currently using is something that /could/ probably be provided in the near future. *However*, there might be a concern that this could be abused by attackers trying to figure out information about the host environment. Either way, you'll have to wait for browsers to finish exposing this to users before it becomes exposed to web applications. As for canvas sizes... The amount of available ram can easily have nothing to do with video graphics surface restrictions. This is a distinct requirement (thanks for listing it). I think it's probably more reasonable for browsers to provide a hint about this than the others. Again there are security concerns, and resource race conditons. But if the number is clamped and can somehow float, perhaps it's workable. Keep in mind that there could be 5 windows side by side each competing to waste e.g. GL contexts on an overly constrained GL based system (the embeddings I'm looking at suck like this). That leaves the i want to dump data to cache case, which is covered by use a timer (even Date()) and figure out if things have slowed too much. For this case, you should in theory start by playing with localStorage and application-cache. Automatically tuning is your user's friend. And it doesn't require any new apis :)
Re: [whatwg] Low Memory Event
All good points. I think as we have moved away from simple web pages and really start to think about applications that are coded in js, many things previously the exclusive domain of desktop apps are more and more desirable for web apps. I also think that a web page should be able to request exclusive access to the graphics card just like many native games do, and that the user need not be aware that anything different has occurred because the browser can simply pause other processes that are not in focus. I realise the technical aspects of doing that are mega complex. For one, each process that is currently using the gpu would ned to be signaled that it no longer has access at the moment and to pause itself, but then again, desktop apps have had to deal with these events for ages. It's been a while but I remember coding a similar event handler for when a user pressed the windows key and suddenly my game was minimised. If I remember correctly, I had to re-initialise direct x or open gl before I could continue processing. Can't we have something similar on a browser with js events? Somewhere down the road I guess! On 28 Sep 2010 00:01, timeless timel...@gmail.com wrote: tl;dr of my previous post: it's impossible to know how much memory is available in the future. How much memory you're currently using is something that /could/ probably be provided in the near future. *However*, there might be a concern that this could be abused by attackers trying to figure out information about the host environment. Either way, you'll have to wait for browsers to finish exposing this to users before it becomes exposed to web applications. As for canvas sizes... The amount of available ram can easily have nothing to do with video graphics surface restrictions. This is a distinct requirement (thanks for listing it). I think it's probably more reasonable for browsers to provide a hint about this than the others. Again there are security concerns, and resource race conditons. But if the number is clamped and can somehow float, perhaps it's workable. Keep in mind that there could be 5 windows side by side each competing to waste e.g. GL contexts on an overly constrained GL based system (the embeddings I'm looking at suck like this). That leaves the i want to dump data to cache case, which is covered by use a timer (even Date()) and figure out if things have slowed too much. For this case, you should in theory start by playing with localStorage and application-cache. Automatically tuning is your user's friend. And it doesn't require any new apis :)
Re: [whatwg] Low Memory Event
On 9/27/10 3:30 PM, Rob Evans wrote: 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! On 27 Sep 2010 23:19, timeless timel...@gmail.com mailto:timel...@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). I'm just talking about the bare minimum: sending a simple event window.dispatchEvent(lowmemory) No details / guarantees. It's just a hint. Mozilla has made efforts to handle low memory issues (allocation errors or otherwise) mainly in the handling of image resources. I'd like to see the practice become more widespread.
Re: [whatwg] Low Memory Event
Indeed, I think to start with this would be very useful. Even if no other info is presented, it would certainly help to mitigate any memory issues as much as possible. If nothing else the running script could act to reduce memory usage. On 28 Sep 2010 00:44, Charles Pritchard ch...@jumis.com wrote: On 9/27/10 3:30 PM, Rob Evans wrote: I think one of the most useful things that a js script could know is how much memory is availab... On 27 Sep 2010 23:19, timeless timel...@gmail.com wrote: what exactly do you intend to do if you get such a signal? In general, this is mostl... I'm just talking about the bare minimum: sending a simple event window.dispatchEvent(lowmemory) No details / guarantees. It's just a hint. Mozilla has made efforts to handle low memory issues (allocation errors or otherwise) mainly in the handling of image resources. I'd like to see the practice become more widespread.
