- From: Charles Pritchard <chuck@jumis.com>
- Date: Sat, 01 Jan 2011 14:04:12 -0800
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 Pritchard<chuck at 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
Received on Saturday, 1 January 2011 14:04:12 UTC