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

Denis Barbier bouzim at gmail.com
Fri Dec 18 11:25:21 EST 2009


On 2009/12/18 Nathan P Sharp wrote:
> Luke,
>   In one of those fantastic moments of AHA at 3am this morning, I perhaps
> struck mental gold.  Instead of using synchronized blocks to protect thread
> access, why not just make the the finalizer proxy the delete request over to
> the Swing thread.  Now you are single threaded again with no sync blocks or
> performance hits.  I spent a few minutes this morning working up how a
> solution might look and am attaching 3 files.  Notes on what I did here:
>
> Apparently since I didn't get enough sleep, I modified the 5.4.2 source
> instead of head.  Sorry.  It compiles but I didn't try it because it needs a
> change to the native side.
> Since the vtkObjectBase is gone and finalized, I had to modify the VTKDelete
> native call to be static and take the vtkID as a parameter.  This is the
> change needed in the native code.
> There is another bug I've found.  What is happening is that nothing is ever
> removed from the global hash, but the c++ memory locations used as a key can
> be re-used once objects are deleted.  This manifests itself as a
> ClassCastException as the wrong java object is pulled out of the hash.  My
> attached code corrects this by removing the Java object from the hash on
> Delete.

Hey, you could have a closer look at Luke's mail, he also mentioned
that bug  ;-)
See http://www.vtk.org/Bug/view.php?id=8942

> I modified Delete() so that calling it multiple times is safe.  This can
> make manually deleting objects safer and easier.  I'm not tied to this
> change, though I think it is a good one.

I agree.  Current code is a bit strange, it is inherited from C++
where Delete() is a synonym for UnRegister() and decrements reference
counter (and frees memory if it is down to 1), but there is no reason
to transpose that to Java.

> Lastly, simply calling SwingUtilities.invokeLater() would actually do the
> wrong thing in my application, which uses a separate ThreadGroup and Swing
> Event Dispatch thread.  So I put a hook in that allows me to override the
> default behavior.  The average won't even know this exists, so it should be
> benign.

May vtkDefaultDispose be a singleton?  That would avoid the creation
of an instance for each vtkObjectBase.
Could you also please post your changes in native code for VTKDelete?
I will then re-send your changes as a patch against cvshead.

Denis



More information about the vtkusers mailing list