Automatic Reference Counting
Apple has now posted some ARC documentation. I love the idea of full garbage collection in principle: less code, fewer crashes, and potentially higher performance. However, due to backward compatibility, iOS, and concerns about bugs in the system frameworks, I have so far only adopted it in a few plug-ins. Automatic reference counting seems to promise the same three benefits to a slightly lesser extent, plus lower memory use, and without the drawbacks. (And the deterministic behavior seems to work very well in Python.) So I think this is a good direction for Objective-C. Overall, though, I tend to agree with Andrew Abernathy:
From my perspective, most obj-c devs think manual ref counting problems overblown, problems of alternatives under-appreciated.
Between autorelease pools and accessors, I don’t have to think about memory management much, and it has not tended to be where I write my bugs.
Update (2011-06-16): Lots of good information from Apple’s Chris Lattner.
5 Comments RSS · Twitter
Agreed. What's interesting about ARC, though, is how it formalized a lot of previously informal conventions, and forces the developer to remove potential ambiguities in object ownership, and clarify the intent of the programmer. That seems like a good thing, at least in theory.
With GC on the other hand, I have the feeling it allows you to sweep more things under the rug, which supposedly lets you focus on more important stuff, but this approach occasionally comes back to bite you.
To be clear, my tweet was in response to a friend's specific comment; I do think that manual reference counting can be a pain even for developers with lots of experience with it, and a big hurdle for developers who aren't familiar with it.
Yes, I do think that many people are overly scared of Cocoa's ref counting, and I do think that many of the same people are under the mistaken impression that garbage collection means no memory management issues, but ARC looks to bring significant simplification, reliability, and even optimization over manual reference counting and, in some respects, garbage collection, without some of garbage collection's drawbacks, and at what appears to be quite minor actual cost to most of us developers, based on our existing programming patterns. Just wanted to make that clarification because I feel that my tweet could be taken more strongly than I intended it.
For the most part memory management is easy. There are some places though where it's awkward and where the GC and (hopefully) ARC offer advantages.
1. Retaining too long - While not a leak as such, you're keeping objects around for longer than needed. ARC and GC can do a better job of reclaiming memory at the best time
2. Dangling pointers - It's hard to do weak references in memory managed Obj-C, as when the object goes away you're left with a dangling pointer. Both GC and ARC support zeroing weak references.
3. Cross thread memory management - GC handles this for you, ARC might but I'm not 100% sure. Hopefully.
@Charles Yes, one of the problems with GC is that so much is implicit. It would be harder to move a GC codebase to manual RC or ARC than the reverse.
@Andrew Thanks for the clarification.
@Martin Well, #1 is interesting because what is the best time? It depends what you are optimizing for. Memory footprint and lack of pauses are probably most important on iOS, thus favoring ARC, but in theory there could be times when it’s better to keep the objects around longer than strictly needed.
[...] to reduce code, it looks like Apple maybe now moving to automatic reference counting (ARC). The links in this blog post provide most of the available [...]
