Generally, non-compacting GCs, and non-compacting/consolidating allocators in general, cannot free memory back to the OS once it's been used.
There are exceptions, such as when the object size is significantly larger than the minimum OS memory allocation size. (By "OS" here, I mean whatever lower level is in charge of allocating memory to the higher level). But generally speaking -- doing a lot of allocation up front is likely to cause you problems later. Especially if that allocation consists of a lot of little objects, and later you need big objects. There may simply be no place that a big object can fit. Compacting collectors solve this by moving objects around. But that takes processing power and increases GC-caused latency. If I recall correctly, Streets of Boston is correct, and the Android folk chose a non-compacting algorithm for these reasons. There may be things you can do. For example, it may work to allocate a bitmap = the largest size you need, BEFORE allocating all your other stuff. This will commit it to having space that large on that side of things, and so long as it doesn't later manage to recycle it, that may make it available to you later. Also, calling System.gc() at suitable points in your initial spike of allocations may reduce the height of that spike, if at the peak, you have some garbage and some non-garbage. This can reduce how much of the memory is committed to the Java side of things. Changing your allocation patterns so that objects with similar lifetimes are allocated and freed (perhaps using System.gc()) can help. This works by grouping things together. If the limitation is on the non-Java side, it would be objects with a non-Java-heap side that would be important here. This is more effective early in a program's life, BEFORE fragmentation develops. Unfortunately, you're getting into territory with no solid, robust, predictable solutions, and you'll have to do some experimentation. The only thing that's 100% reliable is if you can reduce how much memory you simultaneously need. On Mar 3, 2:55 pm, Markus Junginger <[email protected]> wrote: > > catch( Exception e ) > > { > > System.gc(); > > bm = BitmapFactory.decodeResource( resources, R.drawable.my_bm ); > > > } > > > I know it's not the prettiest, but I've never seen the second attempt > > (after GC) fail. > > Interesting. So, what you are saying is that Dalvik's GC does not a > good job freeing memory on its own? > > I'll try if this work around makes it any better. However it is > limited because some of the Bitmaps get loaded during initialization > of layouts, where you can hardly interact. Hmm, a try/catch around > each setContentView also? Boy, this is getting ugly... ;) -- 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
