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