[Gc] Re: Do finalizers run at exit?

Achilleas Margaritis axilmar at otenet.gr
Fri Dec 28 08:02:59 PST 2007

O/H Christophe Meessen έγραψε:
> Achilleas Margaritis a écrit :
>> And another question: why finalization is good after a collection, but 
>> not at program exit? what's the difference? both situations seem the 
>> same to me.
> The answer to this question was already given.

Nope, it was not answered :-).

I asked why finalization is permitted in one place and not permitted in 
another place, where both places are equal; I did not ask why 
finalization is good or bad (at least for the question you replied to).

  A good program design
> should avoid relying on finalizer call of objects allocated on the heap. 
> See Java for a good application of this rule.
> Here are a few reasons I thought of:
> - no control of finalize call order and time (i.e. problem with cycles)

Solved by finalizing objects in graph order, i.e. as Boehm gc does it.

> - in some case, calling finalizers is a waste of time (i.e. program 
> termination)

No, it's not. An O/S will cleanup the resources of a process, but it 
will not magically do things the user is supposed to do. For example, 
deleting a temp file.

> - slows down gc

It does not, if executed in parallel with the rest of the program.

> Suppose you have a circular doubly linked list of objects. How is the GC 
> supposed to know what object to finalize first ? It will have to 
> randomly pick one. But then to preserve validity of the data structure, 
> one would have to add a finalizer so that each object properly remove 
> itself from the list. This object detachment is a pure waste of time. It 
> is particularly obvious when the data structure is destroyed when the 
> program terminates.

On the other hand, suppose you have a temp file that you want to close 
at the end of the program, and your temp file is represented by a 
TempFile class which deletes the temp file upon its finalization. If you 
don't invoke the finalizer, the temp file will not be deleted.

Furthermore, in the example you mention, if a node needs to be removed 
from a double-linked list, order is irrelevant: nodes can be removed at 
any order from the list.

> Thus the rule of thumb is to design your program so that it doesn't rely 
> on finalizer beeing called.

No, I beg to differ. The rule of thumb should be that the programmer 
should have a choice.

> The possibility to call finalizers is there because of the few 
> exceptions where it is required to have them : recycle resources 
> controlled by the destructed object like a file descriptor. 

Which will not happen if finalizers are not invoked.

Keep in mind
> that the program can crash and that the situation where no finalizer is 
> called is a possible use case.

Another important reason why finalizers should be invoked.

> I gave up smart pointers because avoiding cycles requires significant 
> attention and some time more complex design than it should. Beside, in 
> most case all this thread safe counter increment/decrement polka is a 
> waste of cpu resource. Compare the million pointer assignments (i.e. 
> iterators) that may occur in one GC cycle.

I agree with you on this and I wish I could magically transfer this 
knowledge to 100s of C++ programmers who insist C++ only needs reference 
counting and nothing more.

More information about the Gc mailing list