Hi Bill,
> Thanks for the test program and for finding this. A partial
> fix is now on our server. The DisplayImplJ3Ds and associated
> objects are now garbage collected. But there are still some
> Java3D objects that are not (including our VisADCanvasJ3D
> which extends Java3D's Canvas3D). I Tried a few things to
> get Java3D to let go of them but without success.
Thanks for this. GC seems to work much better on the new release.
> One approach is to re-use DisplayImplJ3Ds rather than destroying
> them and constructing new ones. Calls to its removeAllReferences()
> and clearMaps() methods should set a DisplayImplJ3D up for re-use
> (Dave or Curtis please correct me if anything else is needed).
Won't work for me because I often have to change the DisplayRenderer of
my DisplayImpl (DisplayRendererJ3D, TwoDDisplayRendererJ3D). Hence there
is no setDisplayRenderer the only way to do this seems to be
constructing a new display.
> OptimizeIt says that object allocations do not grow for
> RubberBandBoxRendererJ3D. I also saw the apparent memory
> growth using "-verbose:gc" but this may be deceptive.
I looked into the RubberBandBoxRendererJ3D and it looks form me like GC
is doing the whole memory cleanup at a FullGC. So there seems not to be
a memory leak in RubberBandBoxRendererJ3D. So sorry for the false alarm
:)
Cheers, Mathias
