[gclist] Finalizers and reference counting.

[Charles Fiterman]

As systems expand the time taken by collection becomes a fatal problem. One 
company had contracts that said 90% of transactions must be done in 1 
second and the rest in 10 seconds. When the system expanded past 1 GB they 
started to fail, hacking got them past the problem but at some point such 
guarantees must fail.

Reference counting has bugs, it can't deal with cyclic data structures, it 
has excessive overhead but it has some striking advantages. There are no 
serious SMP bottlenecks,  it never has to stop the world. Some languages 
like the latest Perl use reference counting and have garbage collection as 
a backstop.

To the good features of reference counting let me add finalizers. It is 
generally agreed by garbage collection experts that collectors shouldn't 
run user code. We prefer various methods of sending death notices where 
objects need to notify the program of their demise.

Finalizers must be fill five requirements. Sure, objects built get 
finalized. Safe, you can't violate type salty via finalizers. General, any 
code may be in finalizers including exceptions. Prompt, running finalizers 
is not indefinitely delayed. Ordered, finalizers happen in some sort of 
predictable order.

Finalizers run by collectors fail every requirement but safe and sometimes 
fail that. Finalizers run by reference count can fill all the requirements 
though they don't fill ordered very well. In order to fill the requirements 
they may not be part of cyclic data structures.

This suggests languages should be able to declare reference counted objects 
with finalizers. They should also have a way of checking that some objects 
are not part of cyclic data structures. If a reference counted object does 
get collected the collector shouldn't run its finalizer but the user can 
provide for a death notice as a backstop. Perhaps there can be a debugging 
notice of the event.

To the extent that systems can be reference counted they can avoid collection.