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

[Jeff Baumes]

On Mon, Dec 21, 2009 at 4:37 PM, Luke Dodd <luke.dodd at gmail.com> wrote:
>> I meant something like:
>>   package vtk;
>>   class vtkDisposeCurrent implements vtkIDisposeOnThread
>>   {
>>     public void disposeOnThread(long id)
>>     {
>>        vtkObjectBase.VTKDelete(id);
>>     }
>>   }
>>  With this class, current behavior is unchanged, I do not understand
> your objections here.
>
> This would mean that delete was called from the finalizer thread -
> which was the cause of the original errors. (finalizer calls
> finalize(), which in turn calles the disposeOnThread you provided
> which in turn calles VTKDelete). Sorry if I'm misunderstanding this...
>
>>  * Add vtkJavaDisposeCurrent which calls vtkObjectBase.VTKDelete(idf)
> in the current thread (and thus mimic current behavior)
> I believe that vtkJavaDisposeEDT should still be the default behavior.
>
> So the default behaviour should be to not apply any of the patches
> (and thus crashing)? Or are we somehow breaking out of the finalizer
> thread in your code above?
>

He was proposing two implementation options, the event thread one, and
the finalizer thread one. The event thread one would be the default,
but old code that does VTK things on a thread other than the swing
event thread could switch to vtkDisposeCurrent to get the old (buggy)
behavior. The real solution for VTK code not on the event thread is to
make your own disposer that delegates to your thread, but there is no
general way to know what "your thread" is, so that would be up to the
developer to make a custom disposer.

It would also be interesting to see a "no-finalizer" solution. Would
you add a static vtkGlobalJavaHash.gc() method that could be called
manually? Would it be called periodically by another thread (and hence
have the same thread delegation issue)?

Jeff