[vtkusers] VTK/Java crashes -- WeakGlobalRef or garbage collection problem...solution?

[Clinton Stimpson]

On Thursday 17 December 2009 06:55:02 am Jeff Baumes wrote:
> On Thu, Dec 17, 2009 at 6:01 AM, Denis Barbier <bouzim at gmail.com> wrote:
> > On 2009/12/16 Clinton Stimpson wrote:
> >> How does this relate?
> >> <http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/
> >>com.ibm.java.doc.diagnostics.60/html/mm_gc_coexist.html> "The Java
> >> service team strongly recommends that applications avoid the use of
> >> finalizers as far as possible.  The JVM specification states that
> >> finalizers should be used as an emergency clear-up of, for example,
> >> hardware resources."
> >>
> >> Seems to me a can of worms if one attempts to make the garbage collector
> >> thread safe.
> >
> > +1
> >
> > It would certainly be much safer to drop those finalizers and learn to
> > call Delete() when needed.
>
> This could certainly be accomplished by commenting out one line in
> Wrapping/vtkParseJava.c :
>
> fprintf(fp,"\n  protected void finalize() { if (!this.vtkDeleted)
> this.Delete(); }\n");
>
> I agree with the diagnosis of the issue; thanks Nathan for digging
> into this. It appears due the the lack of public outcry in the past
> that the cases that these issues occur are fairly rare. Since we don't
> want to break existing code that assumes garbage collection will take
> care of things, we can make a CMake flag to disable auto-deletion of
> garbage collected objects, which would essentially be this one line
> change to vtkParseJava.c. We would also need to change code in classes
> like vtkPanel to use VTKDelete.
>
> If someone wants to get a patch ready for this, I could look it over
> and commit to CVS head.
>
> The only other solution I can think of is to make all Java-wrapped VTK
> method calls (including finalize()) check a Java mutex lock, to ensure
> that only one thread is accessing the VTK C++ layer at a time. But
> would that affect performance too much?
>

Since finalize can happen on any thread, does that also mean the destructors 
for these classes have to work across threads?

One case I'm thinking of is vtk*RenderWindow where cleaning up of OpenGL 
resources could be thread sensitive.

Clint