Hi Bill,
Thanks for the quick reply.
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.
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.
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?
cheers,
Susan
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
==============================================================================
