Adds MemoryPressureListener.

base/memory/memory_pressure_level_list.h

+// Copyright (c) 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// This file intentionally does not have header guards, it's included
+// inside a macro to generate enum and a java class for the values.
+
+#ifndef DEFINE_MEMORY_PRESSURE_LEVEL
+#error "DEFINE_MEMORY_PRESSURE_LEVEL should be defined."
+#endif
+
+// Modules are advised to free buffers that are cheap to re-allocate and not
+// immediately needed.
+DEFINE_MEMORY_PRESSURE_LEVEL(MEMORY_PRESSURE_MODERATE, 0)
+
+// At this level, modules are advised to free all possible memory.
+// The alternative is to be killed by the system, which means all memory will
+// have to be re-created, plus the cost of starting up from cold.

[Peter Kasting, 2013/06/07 01:00:43]

Nit: starting up from cold -> a cold start

[bulach, 2013/06/07 11:06:58]

Done.

+DEFINE_MEMORY_PRESSURE_LEVEL(MEMORY_PRESSURE_CRITICAL, 2)
+
+// TODO(bulach): REMOVE ME!!!!
+// At this level, the system has no other option but to kill the app.
+// All modules should free as much memory as they possibly can, otherwise the
+// platform will just kill the app.
+// In other words, if a module holds on to a buffer X and the app gets killed,
+// later on the entire app will have to be restarted and the buffer X will have
+// to be recreated. So it's almost always guaranteed to be better to free
+// all possible memory at this pressure level.
+DEFINE_MEMORY_PRESSURE_LEVEL(MEMORY_PRESSURE_SURRENDER_OR_DIE, 2)

[bulach, 2013/06/06 09:28:30]

btw: I don't want this to be funny or anything, but on all the discussions,
including with android members, it seems people don't realize how "critical" the
lack of swap actually is..
I fear that "MEMORY_PRESSURE_CRITICAL" may not be given the attention it
deserves..

so wdyt about replacing "critical" with something a bit more 'frightening'?

[joth, 2013/06/06 22:36:46]

This gets into brinkmanship. IF the system _really_ is that low, it will kill
apps before even sending them this signal, so it's dangerous if this level will
give people too much belief  they don't need to release X at all until this
signal is received.

equally if X is needed to draw the very next frame to screen, dropping it is
silly. So whatever scary wording is put here, it needs to be tempered with the
domain specific estimate on how soon we're going to need to recreate it again
anyway.

[Peter Kasting, 2013/06/07 01:00:43]

I think this SURRENDER_OR_DIE case adds nothing to the CRITICAL case and I would
remove it entirely.

[bulach, 2013/06/07 11:06:58]

Done.