Something about vm gc

It works something like this:

 - Bitmap objects live on the virtual heap
 - Bitmap data lives somewhere else (native heap, mmap() region,
imagination land, whatever)
 - Bitmap objects have an integer field which is actually a pointer to
a native struct, which in turn has width, height, stride, format,
pointer to data, etc.
 - When you release() a Bitmap object, it *should* cause all of the
native storage to be released immediately.

If you don't release a Bitmap object, but you do stop using it, it
will be marked for finalization during the next GC.  Some time after
the GC finishes, the finalizer thread runs, and calls release() to
release the native storage.  On the next GC, the Bitmap object is
collected.

So... if the code holding the bitmaps knows that it no longer needs
them, it can free them quickly.  If it doesn't, and just waits until
the Bitmaps stop being referenced by anybody, then you have to wait
for the finalization thread to do its work after the next GC, which
takes a little longer.  The HeapWorker thread handles finalization,
and runs at normal priority, so it should happen fairly soon.

If the external allocation mechanism didn't exist, and you didn't
explicitly manage Bitmaps or manually call System.gc() with some
frequency, the app would just keep piling up bitmaps, gradually
forcing the system to kill other stuff to make room in.  The mechanism
was added to force garbage collection to happen at "appropriate"
times, and to cause things to break if allocations seemed to be
getting out of control.

Unfortunately the "how much is too much" calculation is too obscure,
and the "can I have memory" mechanism is too simplistic (e.g. there is
no association between an allocation for X amount of bytes and the
Bitmap object that will use them), so it's hard to figure out why
things are broken and how one should fix them.