[vtkusers] VTK and Java Wrappers

[Jeff Baumes]

2010/3/25 Denis Barbier <bouzim at gmail.com>:
> On 2010/3/25 Lars Matthäus  wrote:
>> Add-on: If I run the same program (without vtkGlobalJavaHash.GC() and
>> without .Delete on the vtk objects) using the globalLock solution
>> proposed before it runs for days without crashing or running out of
>> memory. Hence I vote again for using the globalLock implementation in
>> vtk5.6.
> [...]
>
> It has already been committed.

Yes, I am working off of CVS head now. I want to avoid the global lock
solution because this makes it impossible to do VTK processing on
worker threads in parallel. It should be completely safe to work with
disjoint sets of VTK objects (i.e. the sets have no references to each
other) in separate threads. I am aware of at least one person who has
done this in Java, and a global lock would make the worker threads
useless, since only one can be working at a time.

Now, on to the crashes. It can be traced to the fact that the default
behavior was to call GC() once every second on the event thread. Since
TestVTKgc.java works on the main thread, this has potential race
conditions between the main thread and the event thread. In fact,
making this the default puts us in the same situation as before,
except instead of conflicts between the main thread and finalizer
thread, we have conflicts between the main thread and the event
thread. If you do all your VTK processing on the event thread, this
default will do what you want.

Anyway, I just changed the default so you have to explicitly turn on
automatic garbage collection on the event thread if you want it with:

vtkGlobalJavaHash.GarbageCollector.SetAutoGarbageCollection(true);

You should only do this if all VTK processing is done on the event
thread. If that is not the case, you should manually call
vtkGlobalJavaHash.GC() at intervals in your program.

I committed TestVTKgc.java in VTK/Wrapping/Java/TestJavaGCStress.java.
It works for me with these latest changes with no problems, with or
without the Delete() calls.

Jeff