[gclist] Finalizers & Reference counting.

[Boehm, Hans]

> -----Original Message-----
> From: Charles Fiterman [mailto:cef@geodesic.com]
> 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 due to garbage collection time. Hacking got 
> them past the
> problem but at some point such guarantees must fail. At some point
> collection times must exceed any given limit.
You are assuming that memory usage increases without bounds, but processor speed, and the number of processors, remain fixed.  In my experience that's not the general trend.  In the early 80s the general rule of thumb was to configure a machine with about as much memory as it could touch in a second.  My current home PC has less memory than that.  Multiprocessors are more and more common, and GC scales well.

You are also assuming that we can't use incremental GC algorithms.  (I think for C programs that is currently more or less true, but only because the necessary OS support is missing.  And we can't get the OS support in because not enough people care about GC pauses.  Incremental GC is certainly possible if you can insert write barriers, or have enough control to make VM-based barriers work.)
> 
> 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.
Simple reference counting doesn't have top stop the world, but it may pause a thread longer than a GC if you decide to drop all of your data at once.  Unfortunately, I think this isn't very uncommon.
> 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. ...
Finalizers (or death notices) run directly as part of a reference count decrement don't work, for the same reason that it's unsafe to run finalizers directly from the thread that happens to trigger a GC.  The finalizer may need a lock that the thread already holds, resulting in deadlock.  (If locks can be reacquired as in Java, you may got wrong answers instead of the deadlock, but the idea is the same.)  You at least have to enqueue finalizers and run them either in a separate thread, or when the client asks for them to be run.  

Hans