[vtkusers] VTK and Java Wrappers

[David Marshburn]

On Wed, 10 Mar 2010, vtkusers-request at vtk.org wrote:

> ------------------------------
>
> Message: 3
> Date: Tue, 09 Mar 2010 19:31:24 +0100
> From: Lars Matth?us <lars.matthaeus at web.de>
> Subject: Re: [vtkusers] VTK and Java Wrappers
> To: Jeff Baumes <jeff.baumes at kitware.com>
> Cc: Luke Dodd <luke.dodd at gmail.com>, vtkusers at vtk.org
> Message-ID: <4B9693FC.7040304 at web.de>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Jeff and all,
>
> I tested the two solutions proposed in Denis' git branches for two
> months now. I never had a problem with the global lock (Solution 1), but
> one or two non-reproducible crashes with Solution 2. Also, I did not
> experience any performance problems with neither solution. I would
> therefore vote for Solution 1 to be integrated in vtk 5.6.

i, too, vote for the global locks if there are no performance problems. 
i've used the same sort of solution in another java-wrapped library 
(albeit a smaller library than vtk), and it's worked very well.

there's a fair bit of overhead in crossing the java/c++ boundary, so it 
seems plausible that the additional overhead of a lock wouldn't make a 
performance difference.


> But in any case, I'd suggest some stress tests before deciding on the
> issue. It would be good to have an "eternal" loop continuously creating
> vtk objects and let the java garbage collector take care of the memory,
> i.e. of deleting the objects. Ideally, the objects would be
> * simple vtk objects (created directly using native calls like
> vtkPolyData p = new vtkPolyData()),
> * java objects containing vtk objects (implement a small class that has
> vtk objects as members and initialize them),
> * vtk objects containing other vtk objects (e.g. vtkAssembley).
>
> Further, it might be interesting to see what happens if the objects are
> created on different threads.

i'd also recommend chains of objects containing objects.  we've most often 
seen these memory-management-related crashes in sections of code like the 
following:
vtkThis a = something.GetThis();
vtkThat b = a.getThat();
vtkTheOther c = b.getTheOther();
for(...)
{
    // iterate over c
}

when we do this a bunch of times, we see a crash eventually as 'a' or 'b' 
is cleaned up while the program is still iterating over 'c'.  the program 
has to have something else going on at the time, though -- just that loop 
by itself won't generate the crash (i speculate that the garbage collector 
never feels the need to collect anything).  any stress test would need 
something, i think, like another thread that does nothing but allocate and 
re-allocate lots of memory to force the garbage collector to run.


-david