On Mar 3, 10:55 pm, Markus Junginger <[email protected]> wrote: > I have not been able to see the heap size shrink yet. Is there any way > (directly or indirectly) to trigger the HeapWorker manually?
Unfortunately there are multiple concepts that sort of get smashed together: (1) the virtual heap limit, which stretches and shrinks like a rubber band (2) the system's virtual memory, which is a bunch of 4KB pages (3) the heap's "footprint", a description of how much memory is actually used #1 is the easiest to describe and the least useful. The heap initially starts out fairly small (1MB), and the VM will GC as soon as something tries to allocate past that. If the GC can't reduce things far enough, the limit is pushed out. If enough stuff is GCed, the limit shrinks... unless there's an object hanging out there near the end, in which case we can't pull the end back. (It's more complex than this, but you get the idea.) #2 is something you can't really see from within an app. Tools like "procrank" will show page counts rising and falling, but you have to be running a rooted or developer device to really get at that info. #3 is what is used by the external alloc "do I have enough room" calculation. It's computed by the "mspace" code, which is part of dlmalloc. You can kind of see what's going on with the gclog.py script. http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=tools/gclog.py;hb=HEAD Unfortunately the external alloc mechanism has only two calls, "I need N bytes" and "I don't need N bytes", with no indication of what the bytes are for or what object they're associated with. This makes it very difficult to do any sort of analysis when things bloat up. The goal is to move toward a system where the memory is managed by the VM and visible from HPROF, so everything works as expected and the existing heap tools are useful. > 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? Read through this thread: http://groups.google.com/group/android-developers/browse_thread/thread/146a3a354ce3e8e3/61e113036089d696#61e113036089d696 (It's a long discussion in which someone works through a similar situation.) > Back to the external allocation: I guess calling gc+runFinalization > does not make a difference compared to just gc? It needs to be gc + run all finalizers + gc to actually free the storage. Note this applies to anything with finalizers. So, for example, all View objects need a double GC to be freed. (We just removed a bunch of unnecessary finalizers, so future releases should discard your Views more quickly.) If you explicitly release() Bitmaps it still has to go through two GC cycles before it can get rid of the Bitmap object, but at least the pixel data is gone. (Hopefully we can get rid of the finalizers in Bitmap soon.) > 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. Not so -- the virtual heap "footprint" computation should ignore most of the effects of fragmentation. footprint + external allocations must be less than the max heap (16MB or 24MB depending on platform). -- 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
