Hi James-
Thanks for the test program. We find that images (radar
and satellite) use a lot of memory that doesn't seem to
get released. We've always figured it was something down
in Java 3D (after some brief profiling). One of our
next projects will be to nail this down more.
Here are some observations:
- when you call setSample on the FieldImpl, use the
method with a copy signature and pass in copy=false.
Otherwise a copy of your FlatField is made. Only do
this if you are not changing the values underneath
on the original FlatField for each timestep. Do you
do this with your original app? Using that signature
in the RadarMemoryTest really speeds up the test!
- when I run this using copy=false, my max heap
gets up to 89 mb and then stays there. I added
in our ucar.unidata.util.MemoryMonitor widget to
keep track of the memory usage and commented
out it's call to run garbage collection so that
wouldn't affect the results.
- when you are running this test, what do you use for
the heap size in your testing?
- are you using the latest visad.jar (released last
week) in your testing?
- Since you are calling disable/enableAction for
every j, nothing really happens on the inner loop
from the display side. So the memory use is really
from the copying of the data on each set sample.
Thus, the please wait only happens on each J instead
of each i.
- If I add in a ScalarMap of index->Animation and use
ImageRendererJ3D, my memory keeps climbing through the
first few j iterations and levels off at 161 Mb max
heap used, then slowly starts climbing and then finally
levels off at about 200 Mb max heap. Since we use
ImageRendererJ3D for our radar and satellite images, this
explains some of our memory issues. Obviously, there's
a serious leak in IRJ3D. But, it never goes beyond 200
even after 1500 j loops.
This will be a useful program for finding where all
the memory is being used, with or without IRJ3D.
Unfortunately, we probably won't get a chance to look
at this until late March given our schedule. Maybe
someone at SSEC can look into it in the mean time.
Cheers,
Don
James Kelly wrote:
Hi All,
We are having trouble with a memory leak in a real time radar application.
The attached program (RadarMemoryLeak.java) also demonstrates the problem.
The program starts up, reads a single radar image (from the "radar.dat"
file attached), and creates an loop of 18 images from this one image (to
simulate a 3 hour loop of 10 minute images).
If you then hit the "enter key" (at the unix/dos prompt) the program
then simulates new data arriving by:
* resetting all the data (the 18 images) in the loop
* calls setData on the data reference
* loops 1000 times (the "i loop")
* then an outer loop is called up to 10000 times (the "j loop")
On all platforms (Linux, Windows and AIX) I have tested the program will
eventually fail with an out of memory error.
It occurs for both Java 1.4.2/Java3D 1.3.1 and Java 1.5/Java3D 1.4.0 beta.
The number of loops required to crash the program is highly variable.
I've seen crashes for values of j:
* as small as 1 (ie 1000 calls to setData)
* a lot around the 20 to 30 mark
* a few in the hundreds
* rarely more than 1000.
So be patient if you are trying it out.
Can anybody shed any light on what the cause of the memory leak might be?
Many thanks,
James
Attached are:
RadarMemoryLeak.java
radar.dat
To compile/run: download both files to the same directory, then:
javac RadarMemoryLeak.java
java RadarMemoryLeak
Also are attached are text output from from a memory debugger:
* start.txt: the state of the heap memory just after startup
* end.txt: the state of the heap after the "out of memory" error
--
*************************************************************
Don Murray UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000
(303) 497-8628 Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
"Time makes everyone interesting, even YOU!"
*************************************************************
