I've always seen "garbage collector" used as a generic term for an automatic memory management system, not a reference to the specific algorithm used to do it. It could be a tracing garbage collector or it could be using reference counting. Where are you getting the definitions that parent would benefit so from committing to his memory?
While some people might say reference counting is just a form of garbage collection, this blurs the useful distinction when discussing the overhead involved. Automatic memory management schemes that impose a variable runtime cost to analyze the object graph are simply totally unlike schemes that have no analysis step and thus no performance headaches. When people talk about GC being unacceptable for real time systems, they are not saying reference counting is unacceptable as well, they are simply saying that any system with a garbage collection phase are unacceptable. So that seems like a pretty clear split.
Reference-counting schemes don't have the same performance headaches as GC's with an analysis step, they have different ones:
* their own form of pause (when the last reference to a large tree of object disappears) -- this can rule out RC for real-time systems, while there are real-time GCs (though rare)
* a non-local memory access per reference creation (whereas in other types of GC, the cost of allocation can be reduced to a single increment and compare of a value probably stored in a register)
* none of the locality advantages of copying/compacting collectors
Personally I tend to see it as down to whether or not the developer is involved (which dovetails nicely with your reference to automatic memory management).
GC can be implemented via reference counting. But in my opinion, if the developer has to explicitly manage reference counting (e.g. by using "smart pointers" explicitly in C++) I tend to see it as distinct from GC.
