Steven D'Aprano <st...@remove-this-cybersource.com.au> writes: > I've repeatedly asked, both here and elsewhere, why reference counting > isn't "real" garbage collection. Nobody has been able to give me a > satisfactory answer. As far as I can tell, it's a bit of pretentiousness > with no basis in objective fact.
Well, it's a bit of a subjective matter. I'd say it's not real gc because 1) it's unsound (misses reference cycles), and 2) it requires constant attention from the mutator to incr and decr the reference counts. So developing modules for the CPython API means endlessly finding and fixing refcount bugs that lead to either crashes/security failures, or memory leaks. If you program the Java JNI or a typical Lisp FFI, you'll find that real gc is a lot simpler to use since you avoid all the refcount maintenance hassles. You allocate memory and shut your eyes, and the gc takes care of freeing it when it figures out that you are done. Refcounting is basically a form of manual memory management, while gc is automatic. Someone said here recently that as a program gets larger, saying "this will work as long as we do X every time without fail" becomes equal to saying "this won't work". Substitute "properly maintain all ref counts" for X and you can see the problem. I've seen released "production" "tested" Python C modules with subtle refcount bugs on more than one occasion. In gc'd systems there are fewer places for the code to go wrong. -- http://mail.python.org/mailman/listinfo/python-list
