[vtkusers] problems with java memory management

[Mark Roden]

Hi all,

I'm having problems with memory management in java (windows 7, 64 bit and 32
bit, vtk 5.6).

The application loads ~150mb of dicom images (varies from patient to
patient), allocates between 1 to 10 binary masks on top of those images, and
then Does Things, things that include PolyData contours.

Once I'm done with an image, I want to completely wipe all instances of vtk
and start afresh with a new image.

So, I'm calling

vtkGlobalJavaHash.GC();

But that doesn't work, even after I delete all windows and data holders.

So, I go ahead and get more aggressive, calling

vtkGlobalJavaHash.DeleteAll();

This call works somewhat better, but appears to leave ~150 mb behind
(coincidentally, the size of the original image).  When I use the netbeans
memory profiler at this point, I get no indication that this memory is
actually in use; I'm seeing the memory allocations via the system resources
in the task manager.

I then try something a bit more drastic:

    private int DeleteAllVTKObjects(){
        int deleted = 0;
        Set entries = vtkGlobalJavaHash.PointerToReference.entrySet();
        Iterator iter = entries.iterator();
        while (iter.hasNext()) {
            Map.Entry entry = (Map.Entry) iter.next();
            vtkObjectBase obj = (vtkObjectBase) ((WeakReference)
entry.getValue()).get();
            if (obj == null) {
                // Delete a garbage collected object using the raw C++
pointer.
                long id = ((Long)entry.getKey()).longValue();
                vtkObjectBase.VTKDeleteReference(id);
                entries.remove(entry);
                deleted++;
            }
            else if (obj != null){
                // Delete a non-garbage collected object.
                // We use Delete() which will call the "real" C++ Delete()
                // unless Delete() has been called on this Java object
before.
                // Delete() will remove from the map so we don't have to.
                obj.Delete();
                deleted++;
            }
        }
        return deleted;
    }

But that appears to be the same (or no better than)
vtkGlobalJavaHash.DeleteAll().

So here's the deal: I've got ~140 mb leaking with each image that I open,
and the profiler indicates that the leak is not in Java.

I'm using the vtkGDCMImageReader to read in images, and this object does not
(as far as I can see) have a dispose method.  I'm using vtkPolyData objects,
but again, I'm not seeing dispose methods.  I'm using vtkGDCMPolyDataReader
and to handle contours, again, no dispose method present.

So right now, I'm thinking that either those particular classes have leaks
on the C++ side, or some memory is just not getting handled and removed by
the above calls to vtk.

Are there other ways I can debug this issue?  I want the user to be able to
open and close as many images as they want, rather than having to restart
the program every ~10 or so images due to instabilities from the leak.

Also, due to problems I mentioned previously on the list with changes in the
vtk libraries, I can't move to the head version of vtk.  If the head version
has a fix, I can try it, but right now, gdcm and vtk head do not play well
together at all.  It seems that the vtkStringArrays necessary to read in
files on the gdcm side are empty when passed through the java layer in 5.7,
but not in 5.6 (which I discovered through that error << trick from Monday,
thanks for that).  I don't know why that is, but since 5.6 works with gdcm
git head, that's the version I have.

Thanks,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20101123/2e1c5bc2/attachment.htm>