The ARC for Memory Management

Archimedes (287 BC) said "give me a place to stand and I will move the earth".

Apple, after decades of lack of decent garbage collection to Objective-C, seems to say "I will give an ARC to exit to the dark hand-made memory allocation".

Let'see how.

 

It is a small news on Memory Management, but it is one of the new shiny things of MacOS X Lion.

Historically C# and Java programming language has a strong Garbage Collector. It give us easy programming, and reduced tons of bugs. But it has also performance implication.

Objective-C as a C-derived, needed a different approach. We read:

 

Cocoa uses a memory management technique called reference counting. Each object has a reference count associated with it. When some part of an application takes ownership of an object, it increments the object's reference count by sending it a retain message. When it's done with the object, it decrements the reference count by sending a release message to the object. When an object's reference count is zero, it is deallocated.

[...] Simple, right?  Just make sure your retain and release/autorelease messages are balanced and you're golden.  But as straightforward as it is conceptually, it's actually surprisingly easy to get wrong.  Experienced Cocoa programmers will tell you that retain/release memory management eventually becomes second-nature—and it does—but programmers are only human.  Accurately tracking the lifecycle of all objects in a large application starts to push the limits of human mental capacity. [...]

And we add, it was a nightmare. Corba had a similar approach (pinning and unpinning remote object) and every programmer started using EJB and soap to avoid Corba complex nightmare :-)

ARC is able to inject the correct retain, release, and autorelease messages in the code. It is done as a compiler directive.

It sounds magic, but it is an inference game with some naming / implicit conventions:

ARC follows the rules in a more pedantic manner than any human ever would, bracketing every operation that could possibly be influenced by object ownership with the appropriate retain and release messages. This can produce a huge number of memory management operations. Luckily, Apple has an excellent optimizing compiler called Clang (since rechristened by Apple's marketing geniuses as the Apple LLVM Compiler 3.0).  Clang sweeps through this sea of mechanically generated code, detecting and eliminating redundancies until what remains looks a lot like what a human would have written.

[...]

(all via Mac OS X 10.7 Lion: the Ars Technica review, which explains it too well).

Why this solution is clever? First of all, your old Objective-C code without GC gets better, with some code removal and a click on "enable ARC" directive.  This approach is backward compatible with all the bad code written for iMovie, iTune, iFoo Apple does not want to rewrite: they are too busy on iOS6 :-)

Second, ARC is not a GC. It fill in the GAP instrumenting the manual memory allocator in a smart way. So that old Apple Software Architect will not rise calling you a bad guy for performance drop on their super optimized code.

Because memory management is integrated directly into the program flow (innerved) it is very efficient. Like implicit typing, it has the benefit of manual memory management without the need of specifying it.

So ARC is very interesting for a project manager perspective, because ARC aims to be backward compatible with hybrid C/Objective-C code and let us to avoid the release/autorelease horrible dance.

Will we see something similar in Java 10 :-) ?!....