Indeed: there seems to be a consensus among certain very experienced
Java users, including Scott Myers ("Effective Java") and Bruce Eckel
("Thinking in Java"). That consensus is that there are three
conspicuous mistakes in the design of Java: thread groups, classpath
and finalizers.Of course, it doesn't help that even those of us who should know better confuse the Java notion of 'finalizer' with the C++ notion of 'destructor'. They are not as close as they may seem; finalizers are only very occasionally useful since, as you point out, there is no way to be sure they are even called. Now I am not sure this "image data management" was ever described in enough detail for me to be sure the following is appropriate, but there was a very good Google Android blog post on managing a cache for images using "weak references". It is http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html, though you might not guess it from the name;) On Aug 11, 6:13 am, DanH <danhi...@ieee.org> wrote: > 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
