I prefer systems that do not require regular explicit house cleaning in every piece of code that accesses shared data structures. Garbage collection is one means of reducing the explicit house cleaning. Count how many times SvREFCNT_inc() and SvREFCNT_dec() appear in the Perl source code, and figure on the possibility that any of these might be invoked at the wrong time, or not enough times. At this point, I am not even considering performance, or storage. The basic principle is that a less complicated system will probably have less potential to include bugs.

For other examples of the potential for bugs in schemes that rely on explicit house cleaning, such as reference counting, consider the delivery of signals, or the trapping of exceptions. Perl implements an interesting work-around to this problem called 'mortal scalars'. The caller maintains a set of scalars that need to be dereferenced during an unwind operation. Most code, however, creates the scalar first, and then marks it 'mortal' leaving a small window for memory to be leaked.

Issues such as performance are a little less black and white. Anybody can write an inefficient reference counting scheme, or an inefficient garbage collection scheme. For example, earlier versions of Perl used to use a MUTEX lock around all SvREFCNT_inc() and SvREFCNT_dec() operations in the 'thread-safe' version of the code. This is horribly expensive. It is a lot more efficient to implement reference counting using native assembly code, at least for common platforms, as operations like SvREFCNT_dec() can usually be implemented to be as cheap as a standard decrement instruction followed by a test instruction, without the need for thread synchronization.

Reference counting has benefits. As a preference, though, I could live without these benefits, if it improved my level of comfort in the code base.