Hi, The dominator tree shows the largest objects in the heap. It shows only the largest objects that are not retained by one single object.
It's therefore possible that your objects show not up there. Note that currently the information shown by the Memory Analyzer does *not* take the size of "native" objects into account. This is a limitation because the hprof file does not contain this information. Your objects should show up in the history diagram. You should use the "path to GC roots" function in the Memory Analyzer to find out why your GViewGroup are still alive. If you would post screenshots of MAT or maybe even a heap dump, it would be easier to help you. Regards, Markus(http://kohlerm.blogspot.com/) On Oct 19, 1:04 am, John Gaby <jg...@gabysoft.com> wrote: > Thanks for the tip. I have installed the Eclipse Memory Analyzer Tool > and have been able to get a heap dump from my application to inspect, > but I am having trouble interpreting what I see. If I choose to look > at the 'dominator_tree. and sort by package it appears to show my > objects. I have a custom view group 'GViewGroup', and can find each > one listed in the analyzer and I am able match them up with the ones > that I logged as they were created. Each of the GViewGroup objects > has a ImageView object attached to it. To be able to easily identify > these, I created my own custom GImageView class which extends > ImageView. This class adds nothing, except it logs the creation and > finialization of the class. > > Now when I look in the memory Analyzer, none of the the GImageView > objects appear in the list (only the class object for GImageView). > Yet, if I search for the memory address of one of these objects (that > I get from the logging), it shows up. In addition, if I expand one of > the GViewGroup objects, I see that it references a GImageView object. > Why don't the GImageView objects show up in the list. How can I get a > complete list of all the GImageView objects? > > Thanks > > On Oct 18, 12:44 pm, Kostya Vasilyev <kmans...@gmail.com> wrote: > > > > > > > > > If I can make one more suggestion.... since you mention bitmaps.... > > > It might be useful to add explicit Java methods to clean up your objects > > that hold references to bitmaps, and call Bitmap.recycle(). This method > > immediately frees up the memory allocated to hold bitmap bits, leaving > > only the Java stub that's quite small, and can be dealt with by GC at a > > later time. > > > -- Kostya > > > 18.10.2010 23:35, DanH пишет: > > > > Kostya's link was a good one. > > > > On Oct 18, 2:17 pm, John Gaby<jg...@gabysoft.com> wrote: > > >> 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<danhi...@ieee.org> 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<jg...@gabysoft.com> 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<danhi...@ieee.org> 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<daniel.drozdzew...@gmail.com> > > >>>>> wrote: > > >>>>>> On Mon, Oct 18, 2010 at 5:54 PM, Daniel Drozdzewski > > >>>>>> <daniel.drozdzew...@gmail.com> wrote: > > >>>>>>> On Mon, Oct 18, 2010 at 5:40 PM, John Gaby<jg...@gabysoft.com> > > >>>>>>> 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 > > > -- > > Kostya Vasilyev -- WiFi Manager + pretty widget > > --http://kmansoft.wordpress.com -- 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
