On Mar 3, 4:33 pm, Bob Kerns <[email protected]> wrote:
> Generally, non-compacting GCs, and non-compacting/consolidating
> allocators in general, cannot free memory back to the OS once it's
> been used.
I'm not entirely comfortable with that generalization. The HeapWorker
thread wakes up during idle moments and looks for 4K pages with
nothing in them. When it finds them, the memory is made available to
the system again (madvise() system call).
The situation you're describing ("cannot") implies a rather severe
level of fragmentation; at that level you'd be hard-pressed to
allocate anything of moderate size. That doesn't generally apply.
Better to say that compacting VMs are much better at returning memory
to the system, and avoiding situations where large allocations fail
even though there's enough total bytes available.
> Compacting collectors solve this by moving objects around. But that
> takes processing power and increases GC-caused latency. If I recall
> correctly, Streets of Boston is correct, and the Android folk chose a
> non-compacting algorithm for these reasons.
We chose it because it was simple and reliable. Doing it without the
disadvantages you describe takes some effort. Now that we have actual
people dedicated to working on the GC, we're able to put forth the
effort.
> There may be things you can do. For example, it may work to allocate a
> bitmap = the largest size you need, BEFORE allocating all your other
> stuff. This will commit it to having space that large on that side of
> things, and so long as it doesn't later manage to recycle it, that may
> make it available to you later.
The bitmap pixel data is currently implemented using the external
allocation mechanism, which means they're nowhere near the virtual
heap, but the VM is responsible for managing them. "Reserving" space
for bitmap pixels shouldn't make a difference.
As currently implemented the pixel memory isn't discarded until the
Bitmap finalizers execute, and finalizers can't run until after the GC
has finished doing its thing, which is why sometimes allocating a
bitmap twice in a row succeeds when the first try fails.
The external alloc stuff is also getting fixed (veterinarian-style) by
the aforementioned GC people.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
