"... and Dalvik does not seem to make any attempts to shrink its heap size ..." That's what i think as well.
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. Example: Say you are running low on memory, reaching close to the 16MByte limit. E.g you have 14MByte in your app; 10MByte pure java heap memory, 4MByte raw bitmap data. Dalvik sees only the 10MByte. When your try to allocate 3MByte, you'll get a memory exception, because 14+3>16. But since dalvik 'sees' only 10 of these 14 and 10+3<16, dalvik may not even *try* to garbage collect. My app assumes that the above is true, and i'm recycling bitmaps like crazy. If somehow possible, i call recycle on bitmaps that are no longer necessary. On Mar 3, 5:46 pm, Markus Junginger <mar...@greenrobot.de> wrote: > On 3 Mrz., 23:01, Streets Of Boston <flyingdutc...@gmail.com> wrote:> Yes, > you're right. > > I hope I am not, let's see... > > > The OOM exception is thrown if your process' memory would exceed > > 16MByte (or 24MByte on some phones). This includes non-JVM memory such > > as raw bitmap-data. > > That's the easy part. > > > You may have 9MByte available in the java-heap, > > but if your process is still holding on to almost 7MByte of bitmap- > > data memory (which is not part of the java heap), you'll get an OOM > > when trying to allocate more memory. > > This is getting confusing, let me go back to the example to see if we > are on the same track. > > If the heap size is 13M of which 9M are free, it makes 4M of occupied > heap. In theory, that would make a potential 12M for external > allocations (given a 16M limit). My guess is that instead of the 12M > only 3M are actually available on Dalvik. That is, thee potentially > free 9M inside the Dalvik VM heap cannot be used for external > allocations, and Dalvik does not seem to make any attempts to shrink > its heap size. > > Again, these are just my interpretations of what's going on. In the > app there are not even huge bitmaps involved, nor a big number of > them. There's a Bitmap cache involved storing in memory with > SoftReferences as a 1st level and storing to files as a 2nd level > cache. I checked for leaks with Eclipse Memory Analyzer without > finding any. > > > Also, if i'm not mistaken, the DalvikVM's garbage collector is non- > > compacting. > > Which would not make it easier... :/ -- 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
