[gclist] Finalizers and reference counting.
Sat, 17 Aug 2002 07:43:56 -0500
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
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
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.