[gclist] Finalizer flame wars.

[Hans Boehm]

[ I said I wouldn't trust any garbage collector I know of in a safety-critical
system.  Several people took exception.  Charles replied:]

"Huh?? You will have to free storage somehow. Would you use an ad hoc system?
There is nothing wrong with language supported collection strategies. The
moving strategies are quite suitable for mission critical software as they
remove fragmentation."

My impression is that safety critical systems currently do not in general use
dynamically allocated memory.  They statically preallocate all memory they
might possibly need and manage it explicitly.  Since you presumably need exact
bounds on how much memory you need, I'm not 100% convinced that this is always
an intolerable restriction in this context.  It's probably not optimal, and
there may well be garbage collectors that could be acceptable.  But I couldn't
point at one at the moment.  In fact I don't knopw of any that specify hard
space-usage bounds, which seems to be a clear requirement.  (Even SML of NJ
only attempts to bound space usage up to an unspecified constant, as far as I
know.)

Nontrivial garbage collectors, like other nontrivial pieces of software, also
tend to contain bugs that aren't uncovered for a long time.  In my experience,
this is even more true of nonconservative collectors, but we had that
discussion before.

Here I'm assuming that you're talking about something like an aircraft control
system, and you have adequate resources to invest.

[I wrote and Charles responded:]

"> 4. A C++ compiler or its output.  (I might trust a C compiler after manually
> checking its output, and verifying that in addition to being correct, it met
> required resource constraints.  At least at present, I usually have too much
> trouble reading C++ compiler output.)

Huh?? You would trust your ability to write assembler."

Certainly not.  But my experience with commercially released C compilers so far
has been that perhaps 2 out of 3 would compile my garbage collector and test
correctly the first time around.  (I'm not counting bugs related to the fact
that the garbage collector inherently isn't standard conforming.)  Since this
is not a huge program, I don't consider this sort of reliability sufficient for
safety critical systems.  It's better than what I could achieve by hand.  But
it's bad enough that a manual inspection of the code would still buy me some
added confidence.

[Charles wrote:]

"Yes having a reference to a finalizer object makes you a finalizer object. But
finalizer objects are still a tiny minortiy of all objects. The reference count
system doesn't free it only calls finalizers."

I disagree.  In my example, most cord objects could possibly refer to a file
object, and hence would have to be reference counted.  Any object that refers
to a cord would have to be reference counted, since the cord may need to be
reference counted.  Cords are intended to be used as the standard string type
in a program.  What fraction of heap objects can possibly indirectly refer to
strings?  For many of my programs, the number is around 50%.  (Often the most
common exception are conventional flat strings themselves, which know they're
not files.  But they either need to contain a reference count to, so they look
like cords, or code referring to them needs to check for the absence of a
reference count.

Hans