Re: Memory problems with VisAD

Hi all,

A while ago, this thread was started and I was wondering if there was an
update to this memory problem?

My current program has to be able to create a variable number of
displays depending on the data set the user chooses. Because of this, I
don't think I will be able to just simply re-use the displays once I
create them because the number of displays may change unpredictably.

I have been running the  removeAllReferences() and clearMaps() methods
as suggested as well as running destroy() on the display. I notice that
memory use climbs rapidly still, around 5-7MB each time I destroy and
create a new display. Are there any other suggestions to help conserve
memory as I am running into OutOfMemory Exceptions?



Hi Mathias,

> My program dynamically creates displays and their content data,
> them and creates new displays with new data. I realized that after
> creation-destruction operation a portion of memory is not freed. I
> a small example program attached to demonstrate what I mean. Please
> it with "-verbose:gc" to get the needed memory information. You will
> 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
> 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