[vtkusers] VTK/Java crashes -- WeakGlobalRef or garbage collection problem...solution?
Nathan P Sharp
vtkusers at nps.parcellsharp.net
Thu Dec 17 10:18:56 EST 2009
Luke Dodd escribió:
> I'm going to take a look at the global mutex lock and see if it fixes
> the issues I have been having with the Java wrappers. If it turns out
> to be too slow/does not work I'll go for manual Delete calls. I'll
> have a look at this today/tomorrow and report back!
>
> Luke
>
>
Luke,
Thanks to everyone for helping with this. This is a very difficult
problem to work on because when it fails, often the crash is long after
the mistake (which wrote to a bad pointer).
I personally would be in favor of manually deleting objects because
we are also having problems with major memory and GDI handle leaks.
For us VTK is a small piece in a larger application that might be short
lived compared to the process life-span, so static options like
DeleteAll() aren't feasible and I never trust the garbage collector.
As a suggestion, what if you could optionally pass in a
"vtkJavaGarbageCollectionContext" to any object construction. It would
be an unsynchronized map of actual references that would keep my objects
from self-deleting until I know I'm done with the particular chart and
it would allow me to group vtk objects together for cleanup at an
appropriate time. It could fall back on the vtkGlobalJavaHash (and weak
refs) if not supplied for backwards compatibility. A cmake option to
turn off backwards compatibility would be very desirable.
Nathan
More information about the vtkusers
mailing list