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.
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.