Hi,
I have taken a crack at removing the DisplayRealTypeVector logic from
DisplayRealType. I did a brief test and things still seem to work, but I did
not vigorously exercise anything.
One consequence is that two previous instance method of DisplayRealType,
getIndex and getCount, have been removed. Nothing in the main codebase was
using them, so everything still compiles there, but it is conceivable that
someone's code somewhere will break because of it. If anyone complains, I
can reimplement them if necessary.
Please let me know if this change causes problems for anyone.
-Curtis
On Wed, Sep 3, 2008 at 3:27 PM, Bill Hibbard <hiding@xxxxxxxxx> wrote:
> On further consideration, I think someone should just
> remove DisplayRealTypeVector and associated logic
> from DisplayRealType.java, since it is redundant with
> the unique name logic in ScalarType.java.
>
> Bill
>
>
> ----- Original Message -----
> From: "Bill Hibbard"
> To: "Stuart Maclean" , visad@xxxxxxxxxxxxxxxx
> Subject: Re: [visad] memory leak in visad
> Date: Tue, 2 Sep 2008 16:08:06 -0500
>
> Hi Stuart,
>
> The uniqueness of DisplayRealType names and ScalarType
> names is because these classes are often accessed by name,
> and multiple instances with the same name may have different
> properties. This could cause trouble for applications.
>
> I wrote the DisplayRealTypeVector logic, I think before Java
> included WeakMapValue. I also think Steve Emmerson
> probably fixed the logic in ScalarType to use WeakMapValue.
> Neither Steve nor I currently work on VisAD, but if Steve is
> subscribed to this list and wants to make this change that would
> be great. Or if anyone else wants to do it and knows what they're
> doing, that would be great too. Perhaps in cooperation with
> Stuart.
>
> One point is that every DisplayRealType is also a ScalarType
> and hence the uniqueness enforcement in ScalarType should
> serve for DisplayRealType. Why didn't I realize that 12 years
> ago when I was writing this code? Or is there some mysterious
> reason to have this seemingly redundant uniqueness test?
>
> Another point is that DisplayRealType instances don't require
> much memory, so is this a serious memory leak?
>
> Good luck,
> Bill
>
> ----- Original Message -----
> From: "Stuart Maclean"
> To: visad@xxxxxxxxxxxxxxxx
> Subject: [visad] memory leak in visad
> Date: Tue, 2 Sep 2008 13:20:07 -0700
>
>
> I have been using visad and idv classes for offscreen rendering. On
> long lived apps, using IDV's MapProjectionDisplay, I run out of
> memory. My apps are of the form
>
> new MapProejctionDisplay
> add a DisplayableData
> getImage
> destroy
>
>
> Using the jhat heap dump analysis tool in Java6, I think I have found
> the culprit. visad's DisplayRealType has a static vector into which
> all instances are added. There is no method to remove instances from
> this list. So even making sure that names of DisplayRealTypes do not
> clash, my program leaks.
>
> I am happy to fix this locally in the source code, but am unsure of
> the implications, even within this one class. Why must names be
> unique? Can I just add a 'remove by name' method and call this from
> somewhere, probably MapProjectionDisplay??
>
> I note that in ScalarType, use is made of WeakMapValues, in order to
> avoid another memory issue relating to static maps. This idiom seems
> to have not crossed over to DisplayRealType??
> It seems like DRT is almost duplicating uniqueness logic already in
> ScalarType????
>
> Any advice appreciated
>
> Stuart
>
> _______________________________________________
> visad mailing list
> visad@xxxxxxxxxxxxxxxx
> For list information, to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
>
> -- Be Yourself @ mail.com!
> Choose From 200+ Email Addresses
> Get a *Free* Account at www.mail.com <http://www.mail.com/Product.aspx>!
>
> _______________________________________________
> visad mailing list
> visad@xxxxxxxxxxxxxxxx
> For list information, to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
>
> -- Be Yourself @ mail.com!
> Choose From 200+ Email Addresses
> Get a *Free* Account at www.mail.com <http://www.mail.com/Product.aspx>!
>
> _______________________________________________
> visad mailing list
> visad@xxxxxxxxxxxxxxxx
> For list information, to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
>
