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
