On Mar 4, 9:11 pm, Streets Of Boston <[email protected]> wrote: > I think that Dalvik does not 'see' any memory held by raw bitmap data > and therefore cannot consider it during garbage collection (gc). So, > it may not even try to gc when process-memory get low.
Actually, this is why the "external allocation" nonsense exists at all. A problem we faced early on with processes that used lots of bitmaps was that the Bitmap object was very small, but the associated pixel data was fairly large. You could allocate hundreds of Bitmaps without causing a GC (picture a map application with lots of bitmap "tiles"). As you do this, the process grows to a point where everything else in the system is getting pushed out, and the device spends most of its time paging from flash. And if you switch away from the app, everything else struggles until the low-memory killer decides it's time for action. The point of the external allocation tracking was to force the heap to GC when there were lots of Bitmaps. Unfortunately, the design of the Bitmap class makes it difficult for the GC to do its job, because you need to GC then run finalizers to undo the external alloc, and GC a second time to really free up everything. You can't GC and finalize in the same thread without the risk of deadlock, so it's not possible to respond to "hey we're out of memory" with "lets go destroy bitmaps" unless the GC has intimate knowledge of how Bitmap works and can call release() directly. This would be more tolerable if there were a useful way to figure out where all the memory was going, instead of just looking at vague numbers scraped out of the event log. -- 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
