[gclist] gc interface

[D. Hugh Redelmeier]

| "What is usually named "finalizer" outside the world of GC hackers is prompt
| and sure finalization a la Ada."
| 
| As far as I know, that's a recent development in the Ada community, which
| ignored previous usage of the term.  (There are published uses of the term
| "finalizer" by the GC community for "no guarantees finalization"  dating back
| to at least 1985.)

I remember using and hearing the word finalizer in the Ada sense in
the mid 1974/1975 (before Ada).  I don't have a reference.

In C++, destructor nicely matches constructor.  In English,
"initializing" has been more common, so "finalizing" seems a better
match.

In garbage collection, I'm still an agnostic about the concept.  If
the concept can be cleanly formulated, that ought to suggest a name.
"clean up routine" seems to cover my understanding.  The examples
given could be considered to be resource reclamation, in a domain
different from what the GC knows about and manages.

If this characterization is right (not a completely technical issue),
this suggests several things to me:

- the name should reflect this purpose

- the rights and obligations of the code should reflect this

  + perhaps it should be considered as a GC extension, not
    just a part of a particular data structure.

  + perhaps this suggests that if the finalizer wishes to
    re-vivify an otherwise inaccessible object that its object
    refers to (cf. the cycle discussion), it should have the
    right and obligation to "mark" it.

  + if the GC is not allowed to create new stuff on the heap
    during a collection (so that GC cannot fail due memory
    being full when it was invoked), then perhaps finalizers
    ought not to be allowed to create new stuff on the heap.
    More generally, perhaps the restrictions on what a GC can
    do might apply to the finalizer.  The justification is that
    while most of the program code is built "on top of" the
    garbage collection abstraction, finalizer code is part of the
    implementation of that abstraction.

I'm against "finalizer" as just a handy hook upon which to hang code.
I would like a clean abstraction of what is a finalizer (or several
different ones).

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253