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

[Jeff Baumes]

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?

Thanks,
Jeff