On Sep 11, 3:59 pm, Peter Jeffe <[email protected]> wrote: > It seems to me that the issue is a question of time lag more than > anything else. Is it possible that trackExternalFree() isn't being > called soon enough after every de-allocation of external memory?
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. Looking at a couple of data points (without the "RAW" part): > id=".maps" time=128 freed=536576 > > freed=4864 foot=4325376 allow=5308416 objs=49408 bytes=3080192 > > soft=9175040 act=2621440 allow=2621440 objs=43264 bytes=2076672 > > foot=0 total=0 limit=3932160 alloc=3866624 > > 09-11 22:34:02 .maps(725) softlim=8960KB, extlim=3840KB, extalloc=3776KB > freed 4864 objects / 536576 bytes in 128ms > id=".maps" time=122 freed=409600 > > freed=2912 foot=4456448 allow=5701632 objs=49408 bytes=3211264 > > soft=10420224 act=2621440 allow=2621440 objs=43264 bytes=2076672 > > foot=0 total=0 limit=4915200 alloc=4784128 > > 09-11 22:34:20 .maps(725) softlim=10176KB, extlim=4800KB, extalloc=4672KB > freed 2912 objects / 409600 bytes in 122ms What this shows is that the soft limit is in the 9-10MB range, while the actual size is around 4.4MB for 3MB of objects, for the application heap. (You've also got about 2MB on the zygote heap, which are the numbers on the same line as "soft=".) So it would seem that the soft limit is not a good approximation for the mspace footprint in this case, which explains how it could still be going at 13MB+8MB. Your external allocations are around 4.5MB. My best guess is that the issues are a combination of fragmentation in the virtual heap (guess based on the soft limit being so high) plus a large pile of externally-allocated bitmaps (extalloc 5MB here, about 8MB in the first set). The most likely path to success is one that causes the bitmaps to be released sooner. I have zero familiarity with the map code, so I don't have any advice there, but I will ping somebody who may be able help. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
