[vtk-developers] Disturbing garbage collection behavior.

Brad King brad.king at kitware.com
Thu Mar 3 09:04:14 EST 2005


Hi Ken,

Nice analysis.  Please submit this as a bug report, assign it to me, and 
I'll investigate your proposed solution.

Moreland, Kenneth wrote:
>  Consider two VTK objects, A and B, that are garbage
> collected and point to each other.  Furthermore, assume that the only
> reference to B is from A (whereas A has multiple references to it).
> Consider what happens when a method in A executes the following code:
> 
>     A->PointerToB->UnRegister(this);
>     A->PointerToB = NULL;
> 
> The intent of the code is obviously meant for A to drop its reference to
> B.

As you said this code is technically "wrong" according to the current 
garbage collector implementation.  The assumption is that all objects 
have an invariant that each ivar either references a valid fully 
constructed object or is NULL.  This code violates that invariant.

This is actually an argument for using smart pointers more liberally. 
If you look at the destructor of vtkSmartPointerBase you will see that 
it already maintains this invariant using code similar to your 
three-line correct example.  That combined with its assignment operator 
implementation will produce correct behavior for the simple line

   A->SmartPointerToB = 0;

> I think the garbage collector can be corrected by maintaining a set of
> objects that are in the process of destruction.  Whenever a link to an
> object in the process of destruction is encountered, it can be ignored
> with the assumption that it is about to be obliterated as in the code
> above.  I can think of no down side to this approach.

This will probably work.  We can then relax the assumption of the above 
mentioned invariant and this relaxation can be considered a feature of 
the garbage collector.  I'll investigate finding a smooth integration 
into the current implementation.

-Brad



More information about the vtk-developers mailing list