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

[Nathan P Sharp]

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.
    * 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.
    * 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.


 Nathan

Luke Dodd escribió:
> It would be good to hear more about the issues you are having, because
> it sounds like they could well impact me. (I'm bulding a fairly heavy
> swing app)
>
> If indeed any multithreaded access to vtk code, be it mutex locked or
> not, turns out to be a problem there are certainly ways round it.
>
> On the simplest level we could keep the code as it is with my added
> lock and have the finalizer warn you if it objects it's called on are
> not yet deleted by the user. Then perhaps we could add the
> vtkGCContext idea you had. Or... we could periodically sweep through
> the vtkWeakGlobalRef map and look for entries that have become null
> (i.e. garbage collected) and then call delete on them, this could be
> done from whatever thread we wanted and have the advantage of not
> forcing the user to manage memory (then we could eliminate the global
> lock too, although we would still have to be careful). I could look
> into these, but right now I have not actually found it to be an issue
> so it would be great if you could isolate an example case (I know this
> can be very fiddly to do with this sort of code.)
>
> It's no problem working on this - if I manage to nip any threading
> problems in the bud before they rear there heads then I'll be happy!
>
> Luke.
>
> 2009/12/18 Nathan P Sharp <vtkusers at nps.parcellsharp.net>:
>   
>> Luke Dodd escribió:
>>     
>>> As far as threading problems are concerned I would have thought a
>>> global lock would fix things. It does not really matter what thread
>>> any code gets called from as long as there is not more than one thread
>>> messing around with non thread safe code.
>>>       
>> This is entirely true for code you write.  However, when you start
>> dealing with hardware acceleration and heavy packages like Swing, OpenGL
>> and MFC it'll get you in trouble.  Those packages all have very specific
>> rules about what you are and are not allowed to do and often use thread
>> local storage.  In particular OpenGL is tricky because most of it is
>> implemented in drivers by the hardware vendors.  So what works on my box
>> might crash rapidly on someone else's hardware, even for the same OS.
>>
>> http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html
>>
>> I'm frantically trying to get everything I need done before I go on
>> vacation next week.  It might take me a while but I'll get back to you
>> on the sample code for the memory leak.  I agree that it sounds like an
>> unrelated problem.  Again, thanks for working with me.  I look forward
>> to trying out the sync code.
>>
>> Nathan
>>
>>
>>     

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20091218/d7960e39/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkDefaultDispose.java
Type: text/x-java
Size: 456 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20091218/d7960e39/attachment.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkIDisposeOnThread.java
Type: text/x-java
Size: 515 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20091218/d7960e39/attachment-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkObjectBase.java
Type: text/x-java
Size: 2592 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20091218/d7960e39/attachment-0002.java>