On 3 Mrz., 23:01, Streets Of Boston <[email protected]> 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 [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
