How about this test: - Figure out the biggest allowable heap for the device - Start a fresh app that tries to allocate one big ass object that will expand the heap to it's maximum size within a minimal distance of it - GC that object and make sure the "Free Heap" has that big ass object space back - Allocate an object the size of that minimal distance + some extra space The higher the ratio between the big ass object and the OOM object, the higher the chance this issue is real :) (I.e - Very unlikely that after GC's a 20MB object, you would not be able to allocate a 5K due to fragmentation)
On Thursday, March 14, 2013 6:38:47 PM UTC+2, Mark Murphy (a Commons Guy) wrote: > On Thu, Mar 14, 2013 at 12:28 PM, Piren <[email protected] <javascript:>> > wrote: > > There's quite a big discussion of this bug somewhere hidden in the bug > > reports, i've come across the issue myself and found its rather easy to > > replicate. > > > > basically just write a loop that allocate a whole boat load of memory. > run > > it till it poops on you then limit it to do a bit less iterations. that > way > > the heap size will grow to very close to the top limit. > > then drop all the objects to free up the heap (you can even force a GC). > > > > wait a short while to see the heap is truely cleared, then allocate a > big > > object (big enough to pass the difference between Total and Max heap > size > > but smaller than the free heap space). see the world come down and say > > "WTF?" > > > > basically they check memory allocation against the total heap size > instead > > of the free heap size. > > Your scenario doesn't necessarily prove this claim. > > Dalvik's garbage collector is a non-compacting garbage collector. > Hence, you can fragment your heap space, whereby while you have lots > of free heap, but there is no contiguous block big enough to satisfy a > particular request. > > Your "loop that allocate a whole boat load of memory" is fragmenting > your heap space. > > The only way that your scenario would prove your claim is if your > individual allocations in the "whole boat load of memory" are larger > than the request that then fails. > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://github.com/commonsguy > http://commonsware.com/blog | http://twitter.com/commonsguy > > _The Busy Coder's Guide to Android Development_ Version 4.6 Available! > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
