I would consider "reference counting" one of the possible algorithms of garbage collection. Some others being mark-and-sweep and copying and their generational extensions. To me "garbage collection" means I do not have to deallocate memory explicitly.

I would actually like best a GC that'd count references, release immediately everything it can and run a mark&sweep or copy the still live stuff from time to time to clear up the forgotten self-referencing data. Especially since we are used to reference counting in Perl and mostly do make sure we do not forget to break cycles, but we tend to expect that objects are destroyed as soon as they stop being referenced.

I would call reference counting to be one of the possible algorithms of memory management. But many different programming environments have settled on the phrase "true garbage collection" to refer to a memory management scheme that can catch circular cycles. As a result of that I don't like calling reference counting "garbage collection".

On the question of which is better, I have been all over the map. I like reliable destruction mechanics - see my ReleaseAction for proof. But I've also been bitten by internal bugs from reference counting. I've had mod_perl systems whose memory consumption is higher than it should be in part because reference counting caused copy-on-write memory to be written (and therefore copied). I like using closure techniques that naturally lead to cycles and I've jumped hoops to avoid them.

My current preference is that I'd like to see true garbage collection, or else reference counting, and I'd like a hybrid system least. Not the least because I'd be afraid that the reference counting would not get maintained properly and would slowly degrade, while continuing to require a performance overhead.