[vtkusers] Re: is VTKDelete() intended for public use?

Steve M. Robbins steven.robbins at videotron.ca
Fri Oct 7 10:31:02 EDT 2005


On Fri, Oct 07, 2005 at 07:23:45AM -0400, Jeff Lee wrote:
> Hi Steve,
> One way would be to make sure you remove all references to the vtk 
> object, then call System.gc() which will do the finalize, and actually 
> delete the pointer immediately.  

But explicit garbage collection is only a hint, and it is said to be a
bad idea:

    A third category where developers often mistakenly think they are
    helping the garbage collector is the use of System.gc(), which
    triggers a garbage collection (actually, it merely suggests that
    this might be a good time for a garbage
    collection). Unfortunately, System.gc() triggers a full
    collection, which includes tracing all live objects in the heap
    and sweeping and compacting the old generation. This can be a lot
    of work. In general, it is better to let the system decide when it
    needs to collect the heap, and whether or not to do a full
    collection. Most of the time, a minor collection will do the
    job.

    http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html


> I am not opposed to your patch, but 
> VTKDelete has reference counting in it, and if someone else has a 
> reference somewhere, the object won't be deleted anyway.

The java object won't be deleted, no.  But I only care about removing
a reference from the C++ object that holds the resources.

Yes, it is dangerous in that someone may now be holding an invalid
java object.  I can live with that.  It would be even better if the
JNI code would detect and throw IllegalStateException in this
situation.  I bet we could do that without too much trouble.

> For me, explicitly calling VTKDelete is philosophically not the
> right thing to do.  In java, you should make sure the reference tree
> is clean for the object, and then it will be finalized when garbage
> collection occurs.  If the vm is memory bound, then the garbage
> collection will be invoked more often, ensuring that the
> vtkImageData will be deleted shortly after all references are
> removed.

Our software is an image viewer with a mixture of small, short-lived
things (typically generated by mouse events), and very large,
long-lived things (like image buffers).  Hard-won experience taught us
that we should not rely on GC for the latter, for several reasons.  In
practice, this is not an impediment because we know precisely when we
can dispose of the buffer.  Hence our search for a way to dispose of
the VTK C++ objects.

If VTKDelete is not the right method, can we design a better one?

Regards,
-Steve




More information about the vtkusers mailing list