[gclist] Buffy finalizer slayer.

[Charles Fiterman]

At 09:19 AM 6/11/99 -0700, you wrote:

>> For instance, a program which uses finalization to ensure the
>> availability of system resources (by cleaning up redundant resources)
>> is not very reliable.  Such a program will be especially unreliable
>> with a generational conservative collector.  Sooner or later the wrong
>> integers will get on the stack at some point, and at some later point
>> the program will die in an unreproducible way.
>
>It depends on the resource.  If the resource is memory, we have that problem
>already.  In several cases in which finalization is hard to avoid (building
>block for distributed GC, calling explicit deallocation functions in
libraries
>not written for GC) the resource is actually memory.  In other cases (e.g.
file
>descriptors) the resource may be virtualizable so as to make it about as
>plentiful as memory.
>
>Actually, my recommendation would be to use finalization to close file
>descriptors only as a last resort, e.g. to recover from errors.  Code to
>explicitly handle those cases without finalization is likely to be so buggy
>that it will be less reliable than any reasonable finalization
implementation.

The reason I called the article "Buffy finalizer slayer" is that in
addition to being buggy, expensive and unreliable finalizers are absolutely
unnecessary.

Show me an application for finalizers that watcher objects can't do. You've
given me lots of examples of applications that finalizers can't do that
watcher objects can do for example close file descriptors.

In fact show me an explicit application that finalizer objects do
acceptably well.