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

[Luke Dodd]

I'd like to see how people fair with the global lock first, there is
no reason why this and Java finalizers should not be enough to solve
the problem as far as I see (with the addition of manual calls to
delete if we need to free up memory fast or perhaps even advised as
"good practice"). If it turns out this is not true then I would
certainly try other solutions. Like I said before, even my simple
global lock implementation seemed to work wonders for my project - so
I'd like to see how other people fair. The advantage to this is of
course that we don't need to change existing code or do manual
clean-ups on non memory intensive parts of code.

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 global lock would only
ever let one thread into any VTK code, be it the awt event thread or
the finalize thread. So I don't see how any issues could arise.

I take it that the leaking GDI resources are a windows only thing (I'm
developing Linux right now), but perhaps similar things are being
leaked in Linux? Have you got any examples of this that I can look at?
I feel like this could be speperate from this garbage collection
issue. If explicit calls do Delete() do not free what you need then it
seems to me it is either a problem with vtk or the vtkCanvas/Panel
classes in the Java wrappers (that is quite separate from the other GC
issues).

Luke.

2009/12/17 Nathan P Sharp <vtkusers at nps.parcellsharp.net>:
> Luke Dodd escribió:
>> Nathan: Could you explain your suggestion with a
>> "vtkJavaGarbageCollectionContext" a little more? Do you think it is
>> worth doing if the global lock works?
>>
>>
> I'll take anything that works and be happy :-)  However, personally I'd
> still prefer to have explicit control over it (and would sleep better in
> the face of worries about openGL theading restrictions).
>
> Currently even if I go through and explicitly call Delete() on about
> everything I can get my hands on, it is still leaking GDI objects and
> memory.  This might be an unrelated issue, I don't know.  Is there
> something else I should be doing while closing a vtkCanvas?  DeleteAll()
> is not an option because there might be other charts open.
>
> Re: vtkGCContext
>
> I want to get rid of vtkGlobalJavaHash in favor of passing in a
> "context" object.  I want to write code like this:
>
> public class MyVTKChart extends JPanel
> {
>   private vtkCanvas _canvas;
>   private vtkObjectContext _context; //this is really just a map
>
>   pubic MyVTKChart()
>   {
>      _context = new vtkObjectContext();
>      _canvas = new vtkCanvas(_context);
>
>      // create sphere geometry
>      vtkSphereSource sphere = new vtkSphereSource(_context);
>      sphere.SetRadius(1.0);
>      sphere.SetThetaResolution(18);
>      sphere.SetPhiResolution(18);
>
>      // map to graphics objects
>      vtkPolyDataMapper map = new vtkPolyDataMapper(_context);
>      //the object returned by sphere.GetOutput() automatically uses
> _context
>      map.SetInput(sphere.GetOutput());
>      ...
>   }
>
>   //Clear all vtk resources associated with this class.  Only
>   //call after disposing the form
>   public void Delete()
>   {
>      _context.DeleteAll();
>   }
>   ...
>
> Underneath the hood, vtkObjectContext is exactly like vtkGlobalJavaHash,
> only it uses strong references instead of weak.
>
> I really appreciate all your help on this.
>
>  Nathan
>