Thanks guys for all of your replies so far! > 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). I have not been able to see the heap size shrink yet. Is there any way (directly or indirectly) to trigger the HeapWorker manually?
> 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. What you did not refer to is the tons of free memory in the virtual heap in my situation, which is the essential point I wanted to make. So, can you confirm that free memory in the heap is completely irrelevant (HeapWorker is not triggered, etc.) when trying to allocate external resources? Back to the external allocation: I guess calling gc+runFinalization does not make a difference compared to just gc? In the end, I do not think running gc to help Dalvik cleaning up the external allocations won't make much of a difference in my app. With a steadily growing virtual heap (with tons of free sections in it), the space for external allocations decreases over time. > The external alloc stuff is also getting fixed (veterinarian-style) by > the aforementioned GC people. At least there's light at the end of the tunnel. :) Can you hint at a specific release when this will be improved? Thanks, Markus -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
