[gclist] Finalization in the Boehm-Weiser-collector

[boehm.PARC@xerox.com]

Thomas Weitzel wrote:

"I've noticed that when you associate objects with finalization functions in
the
Boehm-Weiser collector, and more than one of those objects are members of a
cyclic graph, the whole cycle becomes uncollectable.

This is a bit unfortunate when one wants to use the collector with C++, because
it is common in the C++ community to use destructors for many other things
beside freeing members.

What is the reason for this behaviour? Can it be changed?"

That is done precisely to guarantee that if A references B and both have
finalization procedures, then A is finalized before B, so that A still sees a
valid copy of B during its finalization.  There is no way to finalize a cycle
without violating this property.

There is a mechanism for breaking cycles (or long chains) when objects first
become inaccessible.  See "GC_register_disappearing_link".

I believe this mechansim is really equivalent to the Smalltalk solution.  In
either case the programmer has to decide what can and can't be used during
finalization.  Cycles involving only data that might be used during
finalization (at least as fasr as the compiler is concerned) result in
finalizers not getting invoked.

(There is also an undocumented way to register a finalization procedure such
that objects it references may be finalized and garbage collected before the
finalization procedure is called.  It's undocumented for a good reason.  It
could be improved to do what Mark Tillotson suggested, in which case it would
at least avoid dangling pointers.  It's really there to support a documented
C++-specific hack, which is to ignore direct self pointers in determining
finalization order.  In my opinion that's also ugly.  But it's necessary since
C++ compilers tend to add such things to implement multiple inheritance.  And
it doesn't introduce dangling pointers.)

Hans
Standard disclaimer ...