NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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? Thanks, -dave --------------------------------------------------------- Hi Mathias, > 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. Cheers, Bill ---------------------------------------------------------- Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706 hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738 http://www.ssec.wisc.edu/~billh/vis.html
visad
archives: