[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