Finalization

One common C++ idiom uses constructor and destructor for resource allocation: resources (including memory but may include others, such as file handles, graphical widgets, etc) that are acquired in a class constructor are released(finalized) in the class'es destructor.

There are, however, two opposing views in how finalization should be handled in a garbage collector. The first assumes that garbage collection simulates an infinite amount of memory and so automatic finalization is inapproriate. The second takes a more pragmatic view, and assumes that automatic finalization should be provided since otherwise explicit resource tracking must be provided by the user for collectable datatypes, making garbage collection much less useful than it can be.

We will refrain from participating in any religious and philosophical wars on which dogma is the ``One True Way''. nstead, both types of collectors are provided.

By default, all garbage collection classes do not perform finalization on garbage collected objects. If object finalization is desired then the user can do one of two things:

• Enable the finalization of the default heap by putting

     GC::get_default_gc().set_finalization(true);

  in the initialization code, or
• Instantiate a different instance of the garbage collector and allocate objects needing finalization from this collector. This may be a better method since not all objects need finalization and those that do not can still be allocated from the default collector. This way we only have to pay for the performance penalty (if any) proportional to the usage of finalization.

For example, if a collectable class named Foo should be properly finalized we can declare it in the following manner:

   extern BGC bgc_f;  // somewhere an instance is defined

   class Foo : public GCObject {
      Resource r;
   public:
      Foo() { r.allocate(); /* allocate resource */ }
     ~Foo() { r.release(); /* release all resource */ }

      // Make object allocate from bgc_f instead
      // of the default non-collectable gc.
      void * operator new (size_t n) { return bgc_f.m_alloc(n); }
   };

When an instance of class Foo is identified as garbage, its destructor will be called. [Aside: currently issue such as finalization synchronization is not handled directly by the collector. So if there is synchronization constraints during finalization it must be handled by the object destructor. Future versions of Prop will provide subclasses with more sophisticated finalization mechanisms. ]

Notice that the default delete operator of all garbage collectable classes will call the object destructor explicitly. It is a good idea to use explicit delete if finalization is a rare need since this service involves an explicit scan of the garbage memory, which may degrade performace with excessive swapping: without finalization the garbage pages will not have to be referenced with a copying collector.

It should also be noted that since the collector is conservative, there is no guarantee that garbage will be identified as such: there is no guarantee that all garbage resources will be released. In general, however, the efficacy of the collector is quite good and so non-critical or plentiful resources can be safely finalized with this collector.

 
• Weak Pointers
• The Heap Walker