[Paraview-developers] garbage collection revisited (hijacked thread)

[Berk Geveci]

Hi John,

Actually, this is not the case. A subclass of vtkObjectBase has to
override Register() and UnRegister() to participate in garbage
collection. From vtkGarbageCollector.h:

// To enable garbage collection for a class, add these members:
//
// \code
//
//  public:
//   virtual void Register(vtkObjectBase* o)
//     {
//     this->RegisterInternal(o, 1);
//     }
//   virtual void UnRegister(vtkObjectBase* o)
//     {
//     this->UnRegisterInternal(o, 1);
//     }
//
//  protected:
//
//   virtual void ReportReferences(vtkGarbageCollector* collector)
//     {
//     // Report references held by this object that may be in a loop.
//     this->Superclass::ReportReferences(collector);
//     vtkGarbageCollectorReport(collector, this->OtherObject, "Other Object");
//     }
// \endcode

If you look at the default implementation in vtkObjectBase, it doesn't
do garbage collection by default. So by limiting the number of classes
that participate in garbage collection to those that definitely take
part in reference loops, we can significantly reduce this overhead.

-berk


On Mon, Mar 4, 2013 at 9:32 AM, Biddiscombe, John A. <biddisco at cscs.ch> wrote:
>>
>
> How do folks feel about garbage collection?
>
>>
>
>
>
> My main problem is that when garbage collection was introduced to VTK, the
> default Delete() was made to use it and FastDelete() was added if you were
> sure you didn’t need GC. Things would have been much nicer if Delete() had
> been left as is, and an extra GCDelete(or similar) had been added and
> inserted in the places where it was known to be needed. There were some
> nasty (if refcount==1 and mapper==this)  type of checks in places which
> clearly needed it, but everywhere else…
>
>
>
> I do realize that you don’t always know when you’re going to  need it, but …
>
>
>
> JB
>
>