[gclist] Some different thinking on finalizers.

[Jerry Leichter]

| I'm not totally gung-ho on the prompt part [for running finalizers] except for 
| file handles. After all if you are on a system that allows 20 file handles you 
| better finalize them promptly....

Let me repeat, very briefly, a proposal I made a while back.

"Promptly" is in the eyes of the beholder.  The reason we don't raise the 
question of whether *memory* is returned "promptly" is that the *allocator* will 
call the collector if necessary to make sure memory is made available when the 
programmer asks for it.  (Alternatively, in continuous collectors, the 
"collection ratio" is set so as to guarantee that the mutator can never "get 
ahead of" the collector and see a memory lack due to insufficient collection.)
As a result, the program itself can never notice that the collector isn't 
"prompt" (though an external observer may complain that it's using more *total* 
memory than he'd like).

You *can* tell that file handles aren't collected "promptly" because there is no 
connection between the file handle allocator and the collector.  In effect, 
you're using the collector to manage collection of a resource that the collector 
doesn't even know is there.  As long as this is the case, no amount of after- 
the-fact manipulation will help.

If you could *tell* the collector that some memory blocks contained the magic 
"file handle" resource, you could modify the file handle allocator to work like 
the memory allocator:  It would call the collector, telling it "I need some file 
handles", and the collector would run until it had found and freed enough blocks 
marked as containing "file handles".  (For a continous collector, one could 
presumably have a collection ratio for each resource the collector knew about, 
in addition to the normal memory collection ratio.)
							-- Jerry