[gclist] Timeliness of finalization

[Hans Boehm]

On Mar 28,  3:26pm, Charles Fiterman wrote:

> You have a list of a million items and it takes a complete collection cycle
> to finalize the first item, then another to finalize the second. This is the
> actual result of some collector finalization algorithms. If the finalizers
> must be run for a correct program result the program is busted.

This is essentially the same as the cycle problem, with the same solutions.  In
my experience, it's even less frequent in real life.  If the ordering doesn't
matter, it's easy to handle in either scheme.  (Assign them the same order
number, or tell the collector to ignore the list links for finalization
purposes.)  If the order matters and you need to finalize multiple objects per
GC cycle, life gets hard either way, at least if you occasionally insert into
the list.  (You would have to tell the collector that order doesn't matter,
have the finalizer add the elements to a data structure, which you then sort
explicitly.  But this is a pretty contrived problem.)
>
> Finalizers must be "sure" to protect encapsulation.

If you mean that they should run at process exit, then I disagree.  Most
resources should be released by the OS.  Otherwise it's not robust against
crashed processes.  You do need to handle resources that are not released.  On
the other hand, you typically do not want to explicitly release resources that
will be released by the OS, since the OS can typically perform the operation
more cheaply.

For those resources that need to be returned on process exit, releasing them is
a very different operation from normal finalization, since global state may
have already been finalized.  Thus I believe it's most reasonable to use a
different mechanism (e.g. registered weak pointers).

Hans

-- 
Hans-Juergen Boehm
boehm@mti.sgi.com