ARC: Cat’s out of the bag

LLVM has posted about the new automatic reference counting feature coming in (I assume) future versions of the compiler.  I have a hard time thinking of this as a helpful improvement in dealing with memory in objective-c in a non garbage collected environment:

  • It doesn’t change the way you think about your allocations.  You still have to place __weak, __strong, or __autoreleased to tell LLVM how you intend to use the declaration.
  • If you’re already declaring your intentions to the compiler, why not simply go the extra step and follow through.
  • The above also holds for the new @autoreleasepool directive to run a local pool.

I also have a few, more personal reasons for not liking the feature:

  • It makes the code uglier: __weak, __strong are not particularly attractive to look at.
  • Alongside the above, I feel it’s a poor abstraction: In a purely garbage collected environment like java or any scripting language du jour, there’s not even a mental model for memory under the hood with the notable exception of scoping rules.  You can simply “new” an object, and it’s there until you either null it out or it goes out of scope.  In the case of ARC, you still have to have be somewhat aware of what you’re doing, but you don’t necessarily need to REALLY understand what’s going on under the hood in terms of the retain count and balancing retain release calls.  As I see it, a clearer and more complete understanding is better than a foggier one any day.  This brings me to my next point:
  • Understanding and managing your memory makes you a better programmer:  There’s something to be said for the level of detail you must think about while working with the memory model in objective-c, and I can’t help but that it pervades the entire application process from design to testing.
  • Is it really all that hard?  Objective-c provides quite clear ownership rules, and with the reference counting built into NSObject, it’s relatively easy to manage memory properly.  Sure, there are plenty of beginner mistakes to be made both with leaking memory and the dreaded EXEC_BAD_ACCESS crash, but now after writing iOS code for a couple years, typing something like [[NSMutableArray array] retain] feels perfectly natural and automatic.

What are your thoughts on adding ARC to your development workflow?


Posted on June 15, 2011, in Opinion and tagged , , , . Bookmark the permalink. 2 Comments.

  1. You won’t need to litter your code with __strong annotations; they’re implied in most circumstances (See section 4.4, Ownership Inference). Generally speaking, programmers with sane codebases won’t need to know or remember much other than method-naming conventions and when to use the __weak qualifier.

    I agree that it’s valuable and important to understand the memory model, but programming is a fundamentally taxing process. Sane models to allow the compiler and the runtime to manage some of the complexity for us are significant advances.

    ARC means that the code we write is shorter, without adding terseness. Fewer scrolling or wrapping lines. Less need to write -dealloc methods, which means fewer opportunities to forget to release ivars or to forget to call [super dealloc]. Fewer objects in autorelease pools just because the coder thought it looked cleaner. Faster autorelease pools when we do need them.

    The whole world has been moving towards garbage-collected code. People have been waiting patiently for GC to come, eventually, to the iOS platform. Instead, Apple leapfrogs GC and replaces the state of the art entirely. In my opinion, ARC is the biggest thing coming down the pipe.

    • That’s true, the __strong is the implied case.

      I’ll reiterate that I fail to see how [anObject release] adds a significant amount of complexity or tedium for that matter. I’m all about allowing the compiler to do work for me. I think the static analyzer is great and works excellently at finding mistakes in the all the instances you listed above plus CoreFoundation issues that it seems the ARC won’t directly address. The autorelease argument is a red herring. Yes, people use it when they shouldn’t, but that’s exactly the point since they’re not following apple’s guidelines for autorelease.

      GC is good thing on desktop platforms and a bad thing on mobile devices for obvious performance reasons. The overhead of a garbage collector on the iPhone with current CPUs would be a disaster, but I’m no processor engineer. I have to think that apple chose not to include it for a good reason. ARC is clearly not a panacea for dealing with the complexities that can arise with memory management, the problem seems to be that it’s an all or nothing proposition for your code (I could be wrong here, the LLVM doc seems to say that’s not the case, but I’ve heard otherwise elsewhere). If that’s the case you don’t have the option to go in and fix it if you need to.

      I feel as though I should go on record to say that I’m not coming at this from a purist standpoint. I like the dot operator for properties. I think blocks are the best thing to make their way into the language since Objc 2.0. This simply seems a poor substitute for a real GC.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: