[gclist] Finalizer flame wars.

[Charles Fiterman]

> I think we're confusing issues here.  The applications I write are not safety
> critical.  If I had to write a safety critical application, I would trust none
> of:
> 
> 1. A conservative garbage collector.
Agreed.

> 2. Any other garbage collector I know of.

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.

> 3. Any malloc/free implementation I know of.

Agreed. Fragmentation is too dangerous.

> 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 abiltiy to write assembler.

> 
> I'm not sure what "mission critical" means.  I do know that GC-triggered
> finalizers allow me to solve problems easily that otherwise don't get solved.
>  The "cord" implementation that comes with my collector sometimes relies on
> finalization to manage file handles.  As a result, it becomes easy to implement
> a "file to cord" conversion function that reads lazily, and the little demo
> editor can handle files larger than swap space.  Very few real editors bother
> to implement this because it's otherwise hard.  As a result, my toy has
> actually been used occasionally to view files that the "industrial strength"
> editors can't handle.  (Don't use it to edit files, though.  Older versions
> have a serious bug writing files back.)

Mission critical means you can't accept program failure. A small editor going
to a dozen users is not mission critical. Microsoft Word with millions of users
should be but isn't. An aircraft navigation program is definately mission critical.

> Could this have been done with separate reference-count-based finalizers?  Yes.
>  But cords themselves, and all objects that reference cords would also have to
> be reference counted.  Thus the garbage collector would be essentially useless.
>  And file access would have been much slower (see
> ftp://parcftp.xerox.com/pub/gc/example.html).

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.
 
> Does it introduce a file handle leak?  In the case of the toy editor, no.  It
> opens at most one such file, which it needs until exit.  In general, it could
> leak handles to files that have become embedded in strings temporarily.  But I
> can't think of a realistic case in which this would matter with probability
> anywhere near that of a power failure.