Of course, finalizers have been all but deprecated on "big" Java. Too unreliable -- not guaranteed to run. If the image data management scheme relies on finalizers it's broken by design.
On Aug 10, 11:54 pm, Bob Kerns <r...@acm.org> wrote: > This has been discussed a fair bit in the past, if you want to try to > look for more details, but the basic issue is that there's a cascade > effect... > > (This was a couple releases ago; it's possible it has been improved > since). > > You call System.gc(). Some finalizers run. This enables other stuff to > be GC'd in the next pass, which allows the bitmap data to be > collected. > > Aside from looping forever until there's enough memory, or detecting > somehow that no changes have been made to the object graph, there's > really no way for a GC implementation to guarantee that one invocation > has actually achieved the absolute best-possible result, when > finalizers are involved. > > This could be better -- but extreme low memory is not what most GCs > are optimized for, so a bit of manual help isn't all that abusive, in > my opinion. The NEED for the manual help is certainly unfortunate, > however, so I hope they do manage to improve the situation. > > On Aug 10, 9:19 pm, DanH <danhi...@ieee.org> wrote: > > > It's kind of abusing the concept. There should be a separate way to > > clean up the image data (and it seems to me it should be self- > > policing, vs having to manually do this). But more obscene things > > have been done in many phones, certainly. > > > On Aug 10, 5:16 pm, Streets Of Boston <flyingdutc...@gmail.com> wrote: > > > > I agree with you, but since the dalvik-vm does not 'see' the raw > > > binary image data in Bitmaps, it may not kick of the garbage collector > > > when process memory gets low. Calling System.gc() explicitly does work- > > > around this problem and it seems to work, in my experience. > > > > On Aug 10, 4:43 pm, DanH <danhi...@ieee.org> wrote: > > > > > I'll add that if you need to call System.gc to prevent an error then > > > > there's a bug in the JVM. (Not saying that there's no bug and hence > > > > no need to call it, just saying that, per the Java spec, the system > > > > should automatically do a GC before raising any "hard" out-of-heap > > > > error. The observations by the others above is presumably an > > > > Androidism, not proper Java behavior.) > > > > > On Aug 10, 3:28 pm, TreKing <treking...@gmail.com> wrote: > > > > > > On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek <coomar....@gmail.com> > > > > > wrote: > > > > > > I think calling System.gc() doesn't immediately trigger the > > > > > > garbage collection. So, relying on this all the time might not be a > > > > > > good > > > > > > idea. > > > > > >http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...() > > > > > > <http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()> > > > > > "When control returns from the method call, the Java Virtual Machine > > > > > has > > > > > made a best effort to reclaim space from all discarded objects." > > > > > > --------------------------------------------------------------------------- > > > > > ---------------------- > > > > > TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago > > > > > transit tracking app for Android-powered devices- 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 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
