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!
_______________________________________________
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
