Hi Susan,
Thanks for the information.
> AnimationControl.setSet(newSet) and DataReference.setData(Field) are
> being periodically called during the stable memory usage case.
> I have done the scenario where there is no data updates, but still
> looping. Except for some initial calls when loading the data, these
> methods are not called. The memory usage is OK.
> So I guess that it is a something to do with the combination of the two
> actions. I have also observed that the speed of the animation does not
> effect how soon the memory is used up.
If neither set of calls (looping; setSet() and setData())
causes a memory leak on its own, it is unlikely that the
combination is a true memory leak. More likely, each of
these asynchronous processes (a looping process, and a
new data process that calls setData() and setSet()) has
periodic memory spikes, and when both are running they
occasionally hit their memory spikes at the same time and
generate an OutOfMemory error.
> Additional Info:
> Some of the overnight runs have resulted in the application being
> aborted. I think it is connected to OutOfMemory error, but I do not
> always get evidence that this has occurred before the crash. It prints
> out the message:
> "An unexpected error has been detected by HotSpot Virtual Machine"
> Information in a log file has:
> Current thread (0x094149c0): Java Thread "J3D-Renderer-1"
> [_thread_is_native, id=14629]
> and there is mention of javax.media.j3d files.
Such errors are always the result of bug in Java, in this
case specifically in Java3D. This could be a non-graceful
reaction of native code to running out of memory, but hard
to know for sure.
> One of my major problems is the inconsistent behaviour in tracking this
> down. Currently, I have a small scenario running via the Netbeans
> Profiler which has been running for 4 days! Could this really be a case
> of needing much more heap memory when looping?
We know that Java3D and 3-D libraries in general often
use amounts of memory that are hard to understand.
The good news is that memory keeps getting cheaper, so
once the hardware, OS's and JVM's all move comfortably
beyond the 32-bit address limit, we should be able to
just throw memory at these problems. Cold comfort now,
of course.
Cheers,
Bill
> On Tue, 2006-06-06 at 02:12, Bill Hibbard wrote:
> > On Mon, 5 Jun 2006, Bill Hibbard wrote:
> >
> > > . . .
> > > > >From running various scenarios I may have narrowed it down to the
> > > > animation process. It was observed that if the application was not
> > > > looping, i.e, playing, the memory usage would become stable and the
> > > > application ran for many days. However, with play enabled, the
> > > > application would run out of memory in a few hours or overnight.
> > >
> > > You observe stable memory usage when the application is
> > > not looping. Are the periodic calls to:
> > >
> > > AnimationControl.setSet(newSet)
> > >
> > > and
> > >
> > > DataReference.setData(Field)
> > >
> > > occurring when you observe stable memory usage?
> > >
> > > If they are occurring when memory usage is stable, that
> > > isolates looping as the cause of the meory leak, and
> > > will significantly narrow the search for a cause.
> > > . . .
> >
> > If the calls to setSet() and setData() are occuring
> > when you observe stable memory usage, then to really
> > isolate looping as the cause of the memory leak it
> > would be useful to run a test with looping enabled
> > but with the calls to setSet() and setData() disabled.
> >
> > Bill
> >
> > ==============================================================================
> > To unsubscribe visad, visit:
> > http://www.unidata.ucar.edu/mailing-list-delete-form.html
> > ==============================================================================
>
>
==============================================================================
To unsubscribe visad, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
