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

Denis Barbier bouzim at gmail.com
Tue Dec 22 05:55:05 EST 2009


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



More information about the vtkusers mailing list