What is this ARC model?

No, ARC is not only an old packer format, nor the company responsible of solid waste removal and recycling services for Chicago and suburbs - this acronym stands for Automatic Reference Counting.

Formerly, class instances used to be manually handled in Objective C code. You had to call explicitly the Release method to decrement its reference count. When an object's reference count is zero, it is deallocated.

This sounds just like our well known reference-counting mechanism included in Delphi, for string, array of, interface or variant. What is new with ARC is that, as with these Delphi types, the compiler will generate the release code. And all those kind of variable instanced are filled with zero (this is not the same as the famous Zeroing Weak pointers feature) - which is implemented by _InitializeRecord() and _FinalizeRecord() in low-level System.pas unit. Of course, the ARC implementation is certainly more sophisticated than the basic implementation in the Delphi compiler: it is told (at least from the marketing paper point of view) to use some deep knowledge of the software architecture to provide an accurate access to all instances. Whereas the Delphi compiler just relies on a out-of-scope pattern.

There is a very interesting analysis of the ARC design available on Ars Technica, which is worth reading. Especially on modest hardware (I do not know if it is honest when this concept is applied to modern smartphones, which are much more powerful than the PCs on which the first Delphi version was running on), Apple's experts say it does make a difference, in term of memory use and program latency - the UI won't glitch during background garbage recycling.

So what about the issues?

This just sounds too much perfect. And there is no perfection on earth, nor in computing.

One common problem with reference counting is the potential circular reference issue.

This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original. Even when all other references to these objects are removed, they still will hold on to one another and will not be released. This can also happen indirectly, by a chain of objects that might have the last one in the chain referring back to an earlier object.

This is where the ARC's Zeroing Weak pointers comes to mind. When you read the official reference material at llvm.org, there are also some other potential issues, but the __weak ownership qualifier is the main point of this document.

The implementation pattern is a bit more complex that the one used for Delphi's interface (taken from Ars Technica):

The "zeroing" part means that weak references will be set to nil when the object they reference is deallocated. (Under ARC, all object pointers are initially set to zero.) Under normal circumstances, an object shouldn't be deallocated if there are still outstanding references to it. But since weak references don't contribute to an object's reference count, an object can be deallocated when there are outstanding weak references to it. When this happens, the automatic zeroing of the outstanding weak references prevents them from becoming dangling pointers. (In Objective-C, sending a message to nil is a no-op.)

As far as I understood the problem, simple types like our reference-counted Delphi variables solve the circular reference issue by providing a copy-on-write behavior. But the interface kind of variable, in its current state, may suffer from this issue.

Since I want to use interface everywhere in our next version of mORMot (to implement a true Domain-Driven architecture - including SOLID principles), some strict rules may be defined in its usage, not to suffer from similar issues. To my understanding, as soon as you use interfaces in the internal scope of methods (i.e. stack-allocated), you may never suffer for circular reference.

Additional investigation is certainly needed.

Your feedback is warmly welcome on our forum!

Article update: Weak pointers and Zeroing Weak pointers have been introduced into mORMot.
See this blog article.