What you're saying is true under some conditions (as i stated, i'm aware of fragmentation)... but i think it will take quite a horrible alignment of stars for it to fail because of the reason you stated... in my tests i wasn't allocating huge chunks, barely 100K or so... i truly doubt every single one of my tests didn't have 100K of contiguous space out of 15+ MB of free space left after the GC.
The test you describe doesn't prove it 100% either though... if Dalvik is a serious asshole it can decide to put 1 byte of data inside the middle of each of the "freed" areas just after the GC (for whatever reason) , that would break the test as well... the only way to 100% prove it is to see the error in the source code. Even mapping the memory and seeing it has enough free space wouldn't help since there might be another (unrelated) issue that causes Dalvik to "miss" contiguous spaces on some occasions. Either way, i had it happen to me and many other users who describes the exact same behavior, i doubt it isnt a real issue :) (though anyway, the way to solve it is the same either case - never allocate so much memory to begin with) 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.
