[gclist] Guardians to finalize objects

[Hans Boehm]

On Apr 4,  1:44pm, Charles Fiterman wrote:

> The collector has the wrong kind of dependency information. A depends on B
> is very different from A's finalizer requires a pre finalized version of B.
> In fact A's finalizer might require a post finalized version of B.
I think we're going around in circles here.  I can't think of a very natural
example of this.  In many cases it's unsafe to access the finalized object,
e.g. if it holds pointers to C allocated data that is explicitly deallocated by
the finalizer.  I certainly don't want access to a post finalized object unless
I go out of my way to get it.

> Finalizer ordering requires mutator semantics which the programmer has and
> the collector doesn't. The belief that finalizer ordering can be derived
> from examining ordinary pointers is merely misleading and results in problems
> like not running finalizers because of pointer cycles or running finalizers
> so slowly that the program ends first.
The finalizer can only access objects it has references to.  Hence we're safe
if we keep those intact.  This may force some objects to stay unfinalized too
long, in the same way that approximating reachability by points-to may cause
some memory to not be reclaimed promptly (or at all).  Thus we may occasionally
need a mechanism to explicitly inform the collector that certain objects will
not be needed for finalization, just as we typically have a (ugly as Henry
points out) mechanism for informing the collector that certain pointers are no
longer needed by the client.  (Note that manually NILing pointers is not
sufficient in the finalizer case, since this needs to happen only after the
objects become unreachable via ordinary means.  Hence the colllector must clear
the pointers, unlike in ordinary code.)

We don't ask user code to explicitly identify which pointers may be followed by
the client.  Why should we handle finalizer code any differently?

>
> If you have a linked list of finalizer objects and the finalizers add lines
> to a report, the desired finalizer order is the desired order of the report.
> No examination will tell you that.
As I've stated before, I don't consider this a reasonable use for finalization.
 If you know in what order the lines should be written, write code that prints
them in the correct order.  The GC should not be involved.  (And if the
collector is generational or conservative, you won't get the lines in the right
order anyway.)

Hans


-- 
Hans-Juergen Boehm
boehm@mti.sgi.com