> I'm not sure why you would say this isn't garbage collection.
Because it isn't. Garbage collection is something that happens at run time by a garbage collector via an algorithm like mark-and-sweep, tri-colour marking, etc, and as a block of code that's called at runtime it A) has a lot of information about your program and B) has a nontrivial performance impact.
Unfortunately I can't talk specifics (stupid NDA), but schrototo has said that it's a compiler-level feature, which would automatically disqualify it as being a bona fide garbage collector.
Speaking generically, any static feature is going to a great deal less powerful than its dynamic equivalent. Thinking of compile-time memory management as garbage collection is not just a leaky abstraction, it's a broken water main flooding into the street.
Think less "auto pilot" and more "cruise control". You still have to understand the accelerator and the break, you just don't have to use them as much.
A garbage collector doesn't need to use an algorithm like mark-and-sweep, or two space copying. It can be something as simple as a system that scans a block of memory looking for any sequence of bytes that appears to be a pointer into managed memory. You don't need special compiler support or extra program knowledge for garbage collection -- conservative collectors can be added to any language, like using the Boehm-Demers-Weiser GC with C or C++.
Automatic garbage collection doesn't even require a garbage collector -- the monolithic piece of code that performs the scanning and reclamation of objects -- it simply requires freeing the programmer from the task of managing the storage of an object. Fancy collector algorithms are meant to improve throughput and latency -- you could definitely create an implementation of Java that uses automatic reference counting but you'd be searching for something faster really quickly.
If I have a language where I create a number of managed objects and the compiler's escape analysis determines that these objects never leave the function's scope and so changes them to be an alloca then you would have garbage collection without involving a garbage collector.
Again, if that's what automatic reference counting is as sold by Apple then I'd consider it to be garbage collection.
For what it's worth, Apple sees this as distinct from garbage collection. For new projects they recommend using ARC, even on the Mac where "real" GC is (and will continue to be) available.
Are you willing to elaborate on this? Recommending it over garbage collection on OS X would run contrary to their previous evangelism of GC and its concurrent scalability.
I can't, since I don't know any more than the next guy reading the docs. I'm sure there'll be an in-depth WWDC session on this and I'm eagerly awaiting the videos.
(I haven't done any Mac OS programming with GC, so I really don't know anything about it, but I've always heard people say the GC is not all that great. So my own uneducated guess is that while GC is messy and complicated, ARC is simple & doesn't have any runtime overhead (they say in the docs that retain/release is now much faster, as is autorelease using the new syntax).)
> Automatic garbage collection doesn't even require a garbage collector -- the monolithic piece of code that performs the scanning and reclamation of objects -- it simply requires freeing the programmer from the task of managing the storage of an object.
Can you back that up? I'd like to see a source that disconnects garbage collection the feature from a runtime garbage collector the implementation of that feature.
Independent of the semantic dispute, I don't think you understand what ARC, the iOS 5 feature, actually is. It's not a technology that "frees the programmer from the task of managing the storage for an object". Just to start with, that is a decision that can only be made at runtime, and as has been discussed ARC is a static-time feature.
Reference counting is very definitely a form of automatic memory management, aka GC. Every GC expert will disagree with your colloquial definition. There are two sides to every reference - the guy who has the pointer and the thing pointed to - and the most efficient GCs use a combination of both. The difference is that the "logical ref count" is distributed for mark-sweep etc, but centralized in object for refcounting.
We're talking past each other. There's "Automatic reference counting, the dynamic garbage collection algorithm that runs periodically at runtime during your program's execution", and "Automatic reference counting, the static compile-time feature that ships in iOS5."
These two things unfortunately share a name, but absolutely nothing else. The iOS 5 feature is not, and has no relationship to, and does nothing remotely like, the garbage collection algorithm with the same name.
Because it isn't. Garbage collection is something that happens at run time by a garbage collector via an algorithm like mark-and-sweep, tri-colour marking, etc, and as a block of code that's called at runtime it A) has a lot of information about your program and B) has a nontrivial performance impact.
Unfortunately I can't talk specifics (stupid NDA), but schrototo has said that it's a compiler-level feature, which would automatically disqualify it as being a bona fide garbage collector.
Speaking generically, any static feature is going to a great deal less powerful than its dynamic equivalent. Thinking of compile-time memory management as garbage collection is not just a leaky abstraction, it's a broken water main flooding into the street.
Think less "auto pilot" and more "cruise control". You still have to understand the accelerator and the break, you just don't have to use them as much.