> My program dynamically creates displays and their content data, destroys
> them and creates new displays with new data. I realized that after each
> creation-destruction operation a portion of memory is not freed. I wrote
> a small example program attached to demonstrate what I mean. Please run
> it with "-verbose:gc" to get the needed memory information. You will see
> that after each button-press an amount of memory will not be freed.
> Because I'm working with huge datasets this behavior kills my system
> every time I try to create a new display after destroying the old one.
> So the loss of memory seems to be very real to me.
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.
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).
> I also recognized the same problem with the RubberBandBoxRendererJ3D.
> The renderer seems to allocate memory during dragging the mouse which is
> not completely freed by the garbage collector (although I'm not really
> sure if this memory is freed after a full GC). See this by running the
> RubberBandBoxRendererJ3D main with the above option. Why does the
> renderer allocate mem during dragging the mouse?
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.
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738