ARC + cyclic references collector vs leading edge GC (say .NET 4.5 GC)

Question

There are a plenty of questions on SO regarding objective c ARC mechanism. Many people asking if ARC is going to replace GC or not, etc. There are even discussions whether it's reasonable to move to ARC from GC for Mac apps(if that does not require much work handling complex references in some data types, etc).

The obvious disadvantage of ARC is complete lack of any mechanism for cleaning cyclic references (edit: cyclic strong references). Here's a very good and simple explanation on memory leaks with ARC What kind of leaks does automatic reference counting in Objective-C not prevent or minimize?

And interesting overview of advantages of apple's ARC over their GC. http://lists.apple.com/archives/objc-language/2011/Jun/msg00013.html

I have a good understanding on how GC works and what kind of problems it has, but moving from C#/.NET world to objective c / Cocoa and reading stuff about ARC I still cannot get one simple thing - why there is no background mechanism to clean cyclic references in ARC application.

It does not require threads suspending, does it? So is relatively cheap to have. Is it a problem to implement one? An light version of GC which scans stack, registers, builds graph, finds cyclic references and frees memory without suspending application threads, sounds cool, no?

Does it require serious computation or other resources? It's hard for me to imagine how to find cyclic references without building all the object graph, but assuming this process is background and continuous it should be ok even in that way?

.NET 4.5 GC (http://blogs.msdn.com/b/dotnet/archive/2012/07/20/the-net-framework-4-5-includes-new-garbage-collector-enhancements-for-client-and-server-apps.aspx) has serious improvements in performance, but having cyclic references collector in ARC system will make second a winner? What are the next steps of ARC system evolution? If it's possible and will sometime happen ARC will have cyclic references collector, can it then fully replace GC, or next gen GCs (with even better performance) are going to eliminate ARC systems?

UPD: Please do not post about weak references, I know how to deal with cyclic references in ARC, and that's obvious, the question is about possibility to add cyclic references collector to existing ARC mechanism, as it would be as powerful and generic as modern GC are

Answer 1

Cycle detection in a C based world requires one of two things:

• all assignments of objects everywhere always go through a write barrier (and, potentially, a read barrier, depending on the features of the collector)

• the scanner must "stop the world" to hold memory in a consistent state when scanning for cycles

The former is a unified memory model and incurs massive overhead compared to straight C (but can be made more efficient than pure manual retain/release). In practice, you typically would "escape" objects from the barrier'd world into un-barrier'd locations using some kind of manual reference count (which is pretty much identical to the bridging mechanisms in the ARC compiler; CFBridgingRetain(), etc...)

The latter is much easier on the developer, but makes performance completely unpredictable as you can never know when, or for how long, any given thread is going to stop. Without barriers, you can't really stop only one thread at a time.

Both of these add significant overhead compared to the relative "at the metal" nature of a C based environment. In a VM based environment, the cost is largely addressed by a combination of the virtualization of the object graph connectivity combined with execution path following JIT compilation that achieves optimizations well beyond what is possible in a pre-compiled environment like C (precompiled, static executables... not the precompiler itself).