[vtkusers] problems with java memory management

[Sebastien Jourdain]

Hi Mark,

I agree it is a common habit in Java. But this problem ONLY if object
is a vtkObject. If it's one of your Java object, this is not a
problem.

Seb

On Wed, Nov 24, 2010 at 3:11 PM, Mark Roden <mmroden at gmail.com> wrote:
> Hi Sebastian,
>
> Thanks for giving me a place to start.  I'll take a look at my various
> pipelines and see where/if I'm doing things like that.  I probably am, since
> that kind of line saving is just what I'd do.
>
> I'll let you and the list know.
>
> Mark
>
> On Wed, Nov 24, 2010 at 9:37 AM, Sebastien Jourdain
> <sebastien.jourdain at kitware.com> wrote:
>>
>> Hi Mark,
>>
>> it might be related to the way you bind vtk object together. I mean by
>> bind something like the following expression.
>>
>> actor.SetMapper( object.GetMapper() );
>>
>> In fact VTK can have some issue with reference count if you provide a
>> VTK object reference across the C++ layer without going through the
>> Java object layer. (Sorry it is not very clear, but it is quite
>> difficult to explain.)
>>
>> So to solve this problem, you should rewrite the above expression like
>> that.
>>
>> vtkDataSetMapper mapper = object.GetMapper();
>> actor.SetMapper( mapper );
>>
>> Hope that helped and please let us know if that solved your problem.
>>
>> Seb
>>
>>
>> On Tue, Nov 23, 2010 at 11:15 PM, Mark Roden <mmroden at gmail.com> wrote:
>> > 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
>> >
>> > _______________________________________________
>> > 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
>> >
>> >
>
>