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

[Denis Barbier]

On 2009/12/22 Jeff Baumes wrote:
> 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.

Exactly, sorry if my wording was unclear.

I pushed another branch java/proxyFinalize2 to gitorious with these
changes.  When writing it, I found that Nathan's implementation is
still subject to bug 8942; finalize() does not call Delete, and thus
object is not removed from the global hash.  Nathan, do you want to
fix it, or do I merge proxyFinalize2 into proxyFinalize?  Or did I
miss something?

> 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)?

BTW, Jeff, could you please have a look at
http://www.vtk.org/Bug/view.php?id=8942
It would be great to have this issue fixed independantly of the
current discussion, so that VTK 5.4 can get fixed too.
Thanks.

Denis