[gclist] Finalization and object orientation.

[Hans Boehm]

On Mar 28,  1:41pm, Charles Fiterman wrote:
> I am considering the following scheme. Objects have an int
getFinalizerOrder()
> and a void setFinalizerOrder(int n) method.
>
> If you need a pre-finalized version of object X you use
>   setFinalizerOrder(X->getFinalizerOrder() + 1);
> which would be abbreviated
>   finalizeBefore(X);

I would guess that you can implement finalizeBefore given the current
Java definition and some conventions.  It squirels away X in a global data
structure, and remembers that this was done.  The finalizer removes X from the
global data structure.

finalizeAfter is harder, but less useful.

> ... What ever problems this kind of scheme has it must be the mutators
> problem not the collectors. If their are cycles and hard to sort out system
> issues they only become harder by handing them to the collector.

I disagree.  I would rather handle the easy cases (in my experience the vast
majority) in the collector, and err on the side of a resource loss (as opposed
to a crash) for the hard ones the programmer forgot to handle.  (Note that the
resource leak is trivial to detect.  Memory smashes in C code are much harder
to deal with.)

I believe there were one or two cases in the (million+ line) Cedar environment
for which finalization cycles were an issue.  They could have been easily
handled with the facility that's now in our collector.  Dealing with cycles is
potentially a tricky system issue.  But it's no trickier than dealing with
programmer determined finalization order.  (Recall that finalization order also
has to deal with transitive dependencies in which some of the intervening calls
involve methods other than finalize().  That makes the above scheme hard, and
it potentially makes cycles hard.  I don't know of a real case in which there's
not an easy way out of the cycle problem.)  And topological order finalization
reduces the number of cases in which you have to worry about it to near
insignificance.

Hans



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