[gclist] Guardians

[Hans Boehm]

On Apr 11,  9:29pm, Carl Bruggeman wrote:

> I am beginning to believe that we have completely different targets
> for finalization.  You apparently use finalization to deallocate C++
> objects and find topological ordering very useful given the contraints
> of C++ and its destroy methods, while I have viewed finalization only
> as a means of managing externally allocated resources using the
> collector, and thus have never had any need for topological
> finalization.

I should have responded to this earlier.  I do not understand what C++ has to
do with this.  To the extent that there is a C++ standard, it says nothing
about destructors invoked from a garbage collector.  (It doesn't say anything
about garbage collection at all.  Stroustrup's modest proposal in that
direction didn't make it in.)  What it does say about destructor order in other
contexts is rather weak, and often requires fairly elaborate kludges (a.k.a.
techniques) to get around.  It's this kind of kludge that I'm trying to get
away from here.

My concern is that

a) Nonresurrecting finalizers generally leave objects in an unusable state.
 (E.g. closed files, objects explicitly deallocated by an OS library or a
library you bought from a third party.  In my experience such libraries tend to
be written in C abd C++.  Even if they were written in Scheme, they might
explicitly deallocate objects and keep them on an internal free list to reduce
GC overhead.  If the objects are large, that typically even makes sense.)

b) Accessing such objects after finalization is bad news.

Thus

c) The finalization facility should make it hard to accidentally access
finalized objects.  If I have to write subtle code to get finalization order
between a file buffer and the underlying file right, in my opinion something is
wrong.  If the scheme breaks with a concurrent collector, something is wrong.

Hans

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