One more noted on this issue. If I put a sleep of 100 ms in
after the setRange(), I don't get the memory problem showing up.
With 10 ms sleep, the problem persists. To me, the interesting
thing is how fast the memory useage creeps up.
Don
John J Brecht wrote:
after reading this:
http://java.sun.com/products/java-media/3D/java3dfaq-1.3.html#memory
and very briefly skimming through this link that it points to:
http://developer.java.sun.com/developer/technicalArticles/ALT/RefObj/index.html
I did a quick experiment and added these two lines:
xmap = null;
xmap = new ScalarMap( RealType.Time, Display.XAxis );
just before the line:
xmap.setRange(then, now);
and it looks like the memory problem goes away. Chances are that Java3D
(especially with VisAD on top of it) is chock full of these "weak" and
"phantom" references mentioned in the article. I didn't read enough of
the article to understand how to properly use the Reference API, but I
imagine building that into VisAD might be the proper solution to this
problem. Meanwhile, trying setting anything to null that you can!
-john
Tom Whittaker wrote:
Doug:
I echo Don's comments "that's some leak". What's interesting is that
if the display (in Don's modified code) is covered up by another
window, the memory starts increasing again (on Windoz). It also
exhibits some interesting behaivor whilst minimized. (I'm using the
-verbose:gc option to watch the GC run.)
Also, periodically, I get this exception:
java.lang.ClassCastException: javax.media.j3d.GeometryAtom
at
javax.media.j3d.TransformGroupRetained.setTransform(TransformGroupRet
ained.java:161)
at
javax.media.j3d.TransformGroup.setTransform(TransformGroup.java:111)
at
visad.java3d.DisplayRendererJ3D.setTransform3D(DisplayRendererJ3D.jav
a:1255)
at
visad.java3d.ProjectionControlJ3D.setMatrix(ProjectionControlJ3D.java
:102)
at
visad.java3d.DisplayRendererJ3D.setWaitFlag(DisplayRendererJ3D.java:1
377)
at visad.DisplayImpl.doAction(DisplayImpl.java:1411)
at visad.ActionImpl.run(ActionImpl.java:303)
at visad.util.ThreadPool$ThreadMinnow.run(ThreadPool.java:95)
No help (sorry), just observations...
tom
--
*************************************************************
Don Murray UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000
(303) 497-8628 Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************
