[vtkusers] VTK and Java Wrappers

[Jeff Baumes]

I have a patch resolving some of the issues raised, shown below with
the commit message. Are there any objections to using features from
Java 1.5 (the patch includes features from 1.5)? Any opinions on what
the default behavior of VTK garbage collection should be (currently
once a second on the event thread)?

http://github.com/jeffbaumes/VTK/commit/5418afd7b6430ded86f0c8746673ed19612b9a8b

ENH: Giving more control of VTK gc to developers.

The finalize() method has been removed from VTK objects, since
finalize() is called on a different thread and may cause concurrency
issues. Instead, we keep a hash table containing WeakReference's in
vtkGlobalJavaHash. vtkGlobalJavaHash.GC() will call VTK's Delete() on
any objects whose weak reference has expired (i.e. they have been
garbage collected by Java). This may be called manually, or may be
called at intervals on the swing event thread by an instance of
vtkJavaGarbageCollector. The default currently is that it is called
once every second on the swing event thread.

vtkGlobalJavaHash.DeleteAll() will delete all native objects in the
hash table regardless of whether their Java objects are still in use.
Therefore this should be reserved for when you will no longer use any
VTK objects in Java, (e.g. at shutdown).

Also included is the fix to Bug 8942 submitted by dbarbier, where the
Java hash could be corrupted when calling Delete manually on objects.

Some tests have been added that demonstrate how the new classes
should work.

vtkX3DBinaryConverter has been removed since it no longer compiles.

CellType is a new Java object that lets you easily access the various
cell types in VTK.

vtkNativeLibrary is a new Java object that facilitates loading the
native VTK libraries.

Jeff

On Wed, Mar 10, 2010 at 3:58 PM, David Marshburn <marshbur at cs.unc.edu> wrote:
> 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
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>