[gclist] Destructors in a heap oriented language.

[boehm.PARC@xerox.com]

Re: Charles proposal:

I don't think the approach of separating normally garbage collected objects
from reference counted, finalized objects is sufficient.  An object that
requires finalization may end up "infecting" most of the other data structures,
forcing them to be reference counted.

A good example of this is the string ("cord") package distributed with our
collector.  It is possible to convert a read-only file to a cord in such a way
that the file is read lazily when the cord is accessed.  It is possible to
concatenate such a cord to another cord, etc.  Thus cords should sometimes be
finalized, because they may have embedded file descriptors, which might be
accidentally dropped.  If you require cords to be reference counted then, if I
understand Charles' proposal, all objects transitively referencing cords must
also be reference counted.  If cords are the normal string data type, this
sounds undesirable.

I disagree with the assumption made here occasionally that file descriptors
should not be reclaimed through finalizers.  This should not be the normal way
of reclaiming them.  But there are cases in which anything else is very hard,
e.g. files embedded in strings, or sometimes files dropped during exception
handling.  If the collector is invoked when you run out of file descriptors, it
doesn't seem very dangerous to let it reclaim them, except possibly with a
conservative collector on systems with a very low file descriptor limit.  Even
then, it seems safer to let the collector try to reclaim accidentally dropped
file descriptors than not.  (The hard file descriptor limit on the machine I'm
typing this (Solaris 2.5) is 1024, which suggests they are not that different a
resource from memory.)

Hans