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
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
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
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
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
interface (taken from Ars
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
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.