It is funny that you mention images, because I am pretty sure that my leak is associated with images not being freed.
Can you point me to a reference that discusses the heap dumping tools? Thanks again On Oct 18, 11:35 am, DanH <[email protected]> wrote: > You probably do need one of the tools that dumps the heap and shows > you the classes of the objects found. > > And do note that Android (outside of the pure Java issues) has > "issues" of its own with regard to image storage. You can obey all of > the Java rules on clearing references and still get bit by Android > images. > > On Oct 18, 12:41 pm, John Gaby <[email protected]> wrote: > > > So there is no way to force all objects that no longer have references > > to them to be garbage collected? > > > Once again, I really don't need to know when the object is actually > > freed. What I am interested in is finding out whether it CAN be > > freed. That is whether all the references to it are gone. In my real > > application, the objects in questions are much larger and more > > complex. Yet, I never see the finalize called for them. This make me > > think that I still have references to them, but since I don't see the > > finalize called even in a simple case where I am sure there are no > > references, I cannot be sure. I definitely have a leak, however, > > since if I perform the same operation enough times, the application > > eventually gets an Out Of Memory error. > > > I am taking a look at using ReferenceQueue, or PhantomReference for > > that purpose but they seem to be way more complicated that I need. > > > Thanks again. > > > On Oct 18, 10:21 am, DanH <[email protected]> wrote: > > > > I doubt that adding content to the object would make it any more > > > likely to be collected. The garbage collector doesn't generally > > > "weigh" objects as to whether they should be collected or not. The > > > only differentiating factors are 1) the absolute size of the object > > > itself (not counting references to other objects), 2) the number of > > > times the object has "survived" garbage collection, and (sometimes) 3) > > > the class of the object. > > > > On Oct 18, 11:57 am, Daniel Drozdzewski <[email protected]> > > > wrote: > > > > > On Mon, Oct 18, 2010 at 5:54 PM, Daniel Drozdzewski > > > > > <[email protected]> wrote: > > > > > On Mon, Oct 18, 2010 at 5:40 PM, John Gaby <[email protected]> wrote: > > > > >> Thanks for the input. I am a little confused about your comment: > > > > > >> 'The fact that you did not see the log from finalize() does not mean > > > > >> it did not happen.' > > > > > > It is possible that the finalize() has been called at much later > > > > > point. > > > > > I should have probably said that lack of finalize() does not mean that > > > > > the memory has not been regained. > > > > > > As Dan points out, finalizers don't necessary run. > > > > > > If Android decided to kill the process running finished application, > > > > > then it would simply do it on a system level, without trying to clean > > > > > the heap within that VM first. > > > > > > If you want to see finalizers at work, allocate many objects that you > > > > > don't hold on to: > > > > > > for(int i=0; i<10000; i++ ) { > > > > > MyClass x = new MyClass(); > > > > > } > > > > > > ...and then call the following: > > > > > > System.runFinalization(); > > > > > System.gc(); > > > > > > You should see your log statements. > > > > > btw, it would also help, if you made MyClass a bit "heavier" say by > > > > adding a member String and assigning to it some longish string literal > > > > in MyClass' constructor. > > > > > -- > > > > Daniel Drozdzewski -- 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
