[gclist] Finalization and object orientation.

[Hans Boehm]

On Mar 28, 12:04pm, Charles Fiterman wrote:
> While you can't guarantee running finalizers at the earliest possable
> moment you can guarantee running them. At end of job you can sort
> remaning finalizers in finalizer order number sequence and run them.
> Approaching the earliest moment is a quality of implementation issue.
>
The problem with static finalizaton ordering is that it's hard to sort out the
system issues.

If I'm implementing a type A and type A objects refer to type B objects during
finalization, type A needs to know type Bs finalization order sequence number.
 The programmer needs to remember finalization order dependencies in order to
get this right.  And getting it wrong in the presence of native methods is
likely to result in memory smashes.

I'm not sure whether this is an improvement over the current Java situation in
which objects of type A need to squirrel away a pointer to the corresponding B
instance in a global data structure until they are finalized.

It still seems to me that the garbage collectors job is already to determine
some approximation of reachability.  Why not use this to determine the
finalization order?  (Yes, I know about circular references.  See
http://reality.sgi.com/emplyees/boehm_mti/finalization.html.)  This approach
has been used successfully in Modula-3, Cedar, and (slightly disguised)
in Smalltalk.

Finalization on process exit is dubious in all these schemes, since it requires
finalizer actions to be be prepared to deal with global variables that have
been finalized.  Charles' scheme probably comes closest to handling it.  But I
don't see how to assign the ordering numbers without violating encapsulation.
 I would prefer to deal with this issue with weak refrences and explicit code
run at process exit.

Hans

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