[gclist] Destructor functions and GC (contains new, I think, idea)

[boehm.PARC@xerox.com]

"The only real-world example I've seen on the list so far where order of
finalization matters (other than because of destructors in legacy code)
is the example of multiple buffers attached to a single file handle,
where the buffers must be flushed before the file is closed.  This
doesn't strike me as problematic ..."

In my mind, the real issue isn't this example, but whether or not it's possible
to give the programmer clean rules for writing correct code.  If you don't have
ordering guarantees, it seems to me that you violate abstraction boundaries all
over the place.  The file buffer contains a file handle.  It shouldn't have to
know whether or not that's a magic integer, or a pointer to another object or
whether the other object has finalization enabled.  If you don't ensure proper
ordering, you're saying that the finalization code may access certain fields
but not others, and which fields may be accessed depends on implementation
internals for those fields.

As Charles points out, imposing the ordering constraint doesn't completely
avoid the problem.  There are still cases in whcih you have to put more stuff
in the interfaces than you would like.  But those cases are even less frequent.
And if you ignore the problem you get an easily detectable leak instead of
incorrect results or a crash.

There are also some other rare uses of finalization which work only in the
presence of topological ordering.  You may have a data structure that's
expensive to reconstruct, and worth recycling into a similar structure, at
least in part.  In that case, the finalization code can "resurrect" the data
structure and put it in a queue for reuse.  If components of the data structure
had previously been finalized, this would probably be less useful.  (I'm told
there were such cases in Cedar, but I don't know the details.)

Hans