Thanks for this excellent explanation. Weird parallel universe indeed! So, right in the onCreate() of my application object, I went and allocated an 8MB array of bytes, causing the heap to grow to 10MB. I then null the array ref and call gc(), which freed up the allocation but left the heap at 10MB. I thought I was moving the "soft limit" up.
My init code runs and starts loading bitmaps left and right for the UI and now it craps out real early, every time. Yipes! I've made things much worse! 04-28 18:01:54.675 D/AppStart ( 1443): memory: T:10756064 - F:8716000 (bytes) 04-28 18:01:54.875 D/dalvikvm( 1443): GC freed 349 objects / 24792 bytes in 108ms 04-28 18:01:55.385 D/dalvikvm( 1443): GC freed 192 objects / 7800 bytes in 92ms 04-28 18:01:55.425 E/dalvikvm-heap( 1443): 115600-byte external allocation too large for this process. So this separate "pile" for bitmaps doesn't grow with the VM heap -- in fact, growing the VM heap made it smaller (I think) because, as you say, that space came out of total 16 MB allocation (?) So what is a good strategy to grab more of my allocation for bitmaps? Preload every single bitmap at startup and keep them around? or? Any insights into how this separate bitmap store behaves (growing/shrinking) is of great interest! I mean, I could always use LESS memory, but dang...it seems like since I am well under-budget 16MB wise, there should be some way to make this work... Thanks -- Ward At 5:05 PM -0700 4/28/09, fadden wrote: >On Apr 28, 1:33 pm, Ward Willats <goo...@wardco.com> wrote: >> So am I really out of memory or just chasing my tail? > >You're really out of memory. > >Bitmap storage exists in a weird parallel universe. The memory isn't >allocated in the virtual heap, but we act like it is when it comes to >deciding if you're out of memory. The per-VM cap is 16MB. > >(Aside: suppose you have 2MB of stuff, and the "soft limit" is 3MB. >You allocate a bunch of objects until you hit the 3MB mark, then a GC >happens. If you free "enough", the soft limit stays where it is. If >you don't free "enough", the soft limit is advanced. This way we're >not allocating physical memory pages that we don't need, but neither >are we GCing constantly. Choosing the right value for "enough" is >something of an art.) > >If you have, say, 4MB of bitmaps, and you start allocating lots of >objects, you will OOM when you hit 12MB of objects. > >Where things get a little quirky is that the opposite isn't true: if >you run out of memory while allocating a bitmap, we don't GC. Freeing >objects won't help unless the soft limit moves. (I think we can >shrink it now, but I suspect we can only do that if there are no >objects sitting out at the end -- remember, the Dalvik GC doesn't do >compaction at this time, which is the main reason why we have this >somewhat bizarre tiered system.) > >If the bitmaps were proper objects on the virtual heap, this would be >less weird, but there's a fair chance you'd still be running out of >memory at this point. > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
