[vtkusers] VTK and Java Wrappers

[Lars Matthäus]

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.

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.

What do you think?
Lars

On 09.03.2010 16:51, Jeff Baumes wrote:
> I agree that we should add a resolution for this issue in the upcoming
> VTK release. The problem is that VTKDelete() happens in finalize(),
> which is run on a separate thread and can cause concurrency issues.
> There are currently 3 proposed solutions (that I know of):
> 
> 1. Use a shared mutex lock around every VTK call (including Delete()).
> 2. Have finalize() dispatch VTKDelete() calls to the thread that VTK
> objects are allocated/used (normally the event thread).
> 3. Have no finalizers, but periodically traverse vtkGlobalJavaHash and
> delete objects whose weak reference is null.
> 
> Denis Barbier has made patches on gitorious for solutions 1 and 2,
> originally made by Nathan Sharp and Luke Dodd:
> 
> I think I prefer the proxyFinalize solution (solution 2 above), but
> others who have more experience with VTK+Java can give their opinions.
> I'll plan to check in a fix in the coming days.
> 
> On Mon, Mar 8, 2010 at 3:06 PM, egk865 at yahoo.com
> <mailto:egk865 at yahoo.com> <egk865 at yahoo.com <mailto:egk865 at yahoo.com>>
> wrote:
> 
>     Back in December, there was a discussion on this list about
>     improving vtk's Java binding to better handle the freeing of vtk
>     resources during garbage collection. Some of the ideas mentioned
>     were global locks or adding a cmake option for disabling deletion of
>     vtk objects during garbage collection and require the user to
>     manually call Delete().
> 
>     With the recent announcement of the upcoming 5.6 branch, I was
>     wondering if any final decisions have been made on this issue. Will
>     there be any changes to the Java wrappers in the next release?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20100309/53436a6f/attachment.pgp>