What I was trying to get at is that if you're relying on System.gc(), you're skating on the edge, memory-wise, tweaking the exact behavior of the GC.
I didn't mean to suggest it's not helpful; I've followed with interest your reports of your experience. But I'd characterize calling System.gc() as an optimization hack, not a workaround for a system problem. By all means, do the extra GC. It can make the difference between a useful and useless app. I was really responding to Stephen's comment: "Is Dalvik such a crappy virtual machine that it can't be bothered to run the garbage collector before spitting out an OutOfMemory exception? " To which the answer is, "no, detects it when it runs the GC. But sometimes in special cases, an extra GC can free up memory that the first one couldn't". Could DalvicVM handle bitmaps better? Yes. But I wouldn't call it a "crappy VM", and it runs the GC before failing. On Jun 9, 8:18 pm, Streets Of Boston <[email protected]> wrote: > For Bitmaps, calling System.gc() can help quite a bit. > The DalvikVM does not 'see' the raw binary data held by a Bitmap. The > process may be getting close to out-of-memory while the DalvikVM > thinks there is plenty.... the DalvikVM does not call a garbage > collection when needed. > > When an allocation happens and the process runs out of memory... > kablooi. > > Calling System.gc() makes sure that the garbage collection is run and > finalizers of de-referenced Bitmap instance are run so that the raw > binary data can be released. > > In my experience, it is actually more 'effective' to call System.gc() > just before you start allocating a big Bitmap, causing finalizers to > run of Bitmaps that then clear/release 'hidden' raw binary data. This > cleans up the process-memory beforehand, not after the fact (after an > OOM-error). > > On Jun 9, 9:35 pm, Bob Kerns <[email protected]> wrote: > > > > > Carefully study the exception type hierarchy. Error and Exception are > > distinct (and deliberately so). You are not catching OutOfMemoryError. > > > But catching an OutOfMemoryError and retrying is unlikely to succeed. > > The VM does GC before throwing the error. It's not entirely pointless, > > however -- occasionally a second GC will be able to collect something > > prior GC was not able to, possibly because of running finalizers or > > similar issues. Putting the call to System.gc() there isn't a > > requirement because of a deficiency in the VM, but rather a > > desperation move for when in desperate straits. > > > It is quite likely that if that GC call helps, you're doomed to have > > another OutOfMemoryError soon, that you won't recover from. > > > I'm NOT arguing against doing it, just putting it into context. It's > > survival mode programming. > > > On Jun 8, 11:39 am, Greg Donald <[email protected]> wrote: > > > > I used this sort of code to make sure my bitmaps load: > > > > try > > > { > > > foo = BitmapFactory.decodeResource( resources, R.drawable.foo ); > > > } > > > catch( Exception e ) > > > { > > > System.gc(); > > > foo = BitmapFactory.decodeResource( resources, R.drawable.foo ); > > > } > > > > In 2.2, it's now failing sometimes and my catch block no longer > > > catches anything. Why would that be? > > > > Is there a better way to avoid a java.lang.OutOfMemoryError ? > > > > Thanks, > > > > -- > > > Greg Donald > > > destiney.com | gregdonald.com- Hide quoted text - > > > - Show quoted text - -- 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
