Garbage Collection redefined in LLVM 3?

I was reading about the fact that LLVM v3 uses a static analysis of the code to implement a sort of automatic garbage collection that is prepared and done during compilation.

If the compiler statically inserts retains and releases then no runtime component for garbage collection is needed anymore or 开发者_开发知识库what?

Is this true? Will it work as a replacement of normal garbage collection either on iOS and OS X development? It is not clear what will happen..

Should we rely this kind of "static garbage collection"?

This is an interesting question: can a static analyzer implement a complete garbage collection system?

The answer, it appears, would be no. The only way to implement garbage collection is knowing that an allocated piece of memory (e.g. an object instance) is no longer useable. In a runtime GC, this knowledge is gained by (effectively) scanning the stack and heap. Doing this at compile time would require analyzing all possible code paths through the system to determine where in its execution a particular allocation would no longer be reachable. This is equivalent to the halting problem. However, LLVM claims to support at least a limited form of automatic reference counting (inserting retain/releases) for you. See http://developer.apple.com/technologies/ios5/. I suspect that what LLVM is doing is not a full GC, it's using the static analyzer to find when all references to an object go out of scope, and inserting appropriate retain/releases for you. The reference counting happens at run time, just as before. I highly doubt that it will do automatic free-ing of malloc'd blocks for you.

If it works as advertised on the public site above, I'd say use it.

If the compiler statically inserts retains and releases then no runtime component for garbage collection is needed anymore or what?

ARC stands for "Automatic Reference Counting" and, therefore, resorts to reference counting (RC) in general. RC is one of the oldest forms of garbage collection dating back to 1960 and is rarely used in practice because it is very slow, incurs unbounded pauses and is inaccurate because it leaks cycles.

RC is slow because reference counts are incremented and decremented every time you handle a reference to an object (e.g. read a reference from the heap or write one into the heap) and thread safe reference counting must adjust counts using atomic increment and decrement operations. Naive reference counting (e.g. shared_ptr in C++) is ~10x slower than tracing garbage collection. ARC uses static analysis to remove some of these counter increments and decrements which will improve performance but I am not aware of any benchmarks and I seriously doubt the result is competitively performant when compared to, for example, the JVM or CLR (both of which ditched reference counting long ago because they found tracing garbage collection to be a lot faster and more accurate).

What you heard is right. See "Automatic Reference Counting" at http://developer.apple.com/technologies/ios5/. If you are a registered developer, you can read much more about ARC in the "What's New" documents recently released (under NDA).