Re: [gclist] Finalization and object orientation.
Fri, 28 Mar 1997 15:39:59 -0600
>This is hardly a bogus assumption, and it is not solely a result
>of C++ quirks (though it is reasonable to make the default assumption
>that anything inherited from C++ is bogus). In my view of the world,
>if anything referred to by a finalized object may or may not be in
>some weird state (because it, too, was finalized) then it is difficult
>to regard that object as having "added value". (If you disagree with
>this assumption of mine, then the rest of my argument makes little
>sense, but I will continue).
This is a brand new ... TODAY ... generalization about the usefulness
of finalizers in OO, so prepare for a shift in thinking. A finalizer
is simply a function called when the collector detects an object is
unreachable from the roots. It should NOT violate the objects invariants
and leave it in a bogus state. A closed file object isn't bogus, its
semantics simply say raise an exception if sombody tries to write to
you and those are very good semantics.
Imagine a simple list of objects, each object has a finalizer that
uses the next object on the list to add to a total if there is a
next object. The list gets finalized from the tail first. The finalizers
add to the usefulness of objects in a perfectly orderly way.
>So, in order to ensure that things
>referenced by a finalizer have not yet been finalized, the finalizer
>ordering problem reappears. The question of what to do about finalizable
>cycles reappears (rare in Cedar, people at Xerox assert, but unclear
>whether that will be true in Java, where every object inherits a finalizer,
>though the default is trivial). To run finalizes in order and avoid
>finalizing a resurrected object, the garbage collector either finalizes
>very slowly, or employs write-barriers to detect resurrection. Given
>the costs of the generality that you advocate, I find that I am very
>comfortable with Java's more limited approach to finalization.
Again what ever problems there are in deciding finalizer order they belong
in the mutator not the collector.
Charles Fiterman Geodesic Systems
414 North Orleans Suite 410 Phone 312 832 1221 x223
Chicago IL 60610-4418 FAX 312 832 1230
A computer language without garbage collection
is like a city without garbage collection.