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
--
john brecht
sri international
john.brecht@xxxxxxx
650 859 2325
