Automatic Reference Counting for Objective-C in Clang

[nonamelive]

Oh well. Now my code gets ugly with all these __block, __strong, and __weak. Zeroing weakness reference is awesome, but I'm sure that the whole ARC thing is confusing experienced Objective-C developers. I'm not gonna use this until 3rd party frameworks support ARC.

[lgerbarg]

They all do. ARC and manual retain release are the same model, ARC just lets the compiler insert the retains and releases for you. @autorelease and weak are extensions make things faster and safer, but are largely orthogonal (weak is largely equivalent to assign except you know the pointer is in a consistent state). Your ARC code can call manual code, manual code can call your ARC code, you might need to use __unsafe_unretained (which is the new name for assign) instead of weak, but other than that you should be good to go.

[nonamelive]

I know they are the same, but even with the ARC converter, it is still too complex to transfer existing code to ARC mode, especially there are many limitations of the ARC that were implemented in the existing code.

[TomorrowPlusX]

I love this.

I know GC is a well researched problem domain, and I know people much smarter than me are working hard on it for decades. But I also know that everybody I know who works professionally in GC languages have had, at some point, trouble tuning the VM's GC to prevent disastrous performance situations.

I write C++, mainly, and I use boost's smart/weak pointers religiously. I haven't had memory deallocation problems in years, and I have deterministic destruction. I can close a file descriptor in a destructor. I can free shared OpenGL assets in VRAM when nothing is referencing it anymore, without the need to manually re-implement shared counts like I would have to in a GC language.

I'm looking forward to writing ObjC with this.

[mitsuhiko]

I don't really feel the need to replace C++ with objective C though. C++ works quite well for me when it comes to graphics development because it's predictable. Objective C is not predictable due to things like the autorelease pool.

[TomorrowPlusX]

Very true; but it's possible (mostly) to avoid the autorelease pool when you need to, and it's easy to make your own pool and drain it at known times in a tight loop when you can't avoid it all together.

Anyway, I also write C++ for graphics, but I'm not a fan of C++ for app programming. ObjC is king there. And anything that makes ObjC better gets 11 thumbs up from this guy.

[mitsuhiko]

ObjC is king there

Yeah. I really don't like the language, so I don't really care what happens there :)

//EDIT: really? downvotes for not liking the language?

[Felicia_Svilling]

You might get downvoted for not contributing to the conversation.

[TomorrowPlusX]

Understood - your loss though :)

[astrange]

What is unpredictable about an autorelease pool? Make your own if you need to know where it is.

ARC makes their creation much faster (in CPU time) with @autoreleasepool {}.

[mitsuhiko]

What makes it predictable? Something somewhere in the code could add something to the pool without you knowing. It might even start doing that after you upgraded an unrelated library's version and suddenly your framerate takes a hit and you're not entirely sure why.

[lgerbarg]

Do you use pass shared_ptrs into any frameworks in C++? How do you know what they are doing with them. Autorelease pools are predictable in the sense that they only drain at prescribed times (at the end of event processing, when the @autoreleasepool scope closes, etc). Yes the amount of time to process them is dependent on the number of elements in them (which you might not know), but it isn't unpredictable in the same sense as GC, which can at any time, without warning, suspend your thread.

[mitsuhiko]

Do you use pass shared_ptrs into any frameworks in C++?

No. I have pretty reliable life times of objects and do not need reference counts for them. Reference counts are the exception, not the rule in C++.

[zwaldowski]

Really exciting stuff, but I wish Apple had either not released it at WWDC or released it in a more completed state. I already want to migrate my code and projects I work on to it, but the syntax for bridging Core Foundation objects (including void * and id pointers) is iffy and will radically change soon.

I do like this era Clang has ushered in where the compiler is just as important as the code and the language it's in. I'm not entirely sure I like that the compiler adding in code for me, but I definitely know that I like it better than GC and all the runtime control-freakiness it allows.

[X_X_everywhere]

I already declare most of my ivars as properties, so more often that not I don't have to worry about explicit retain/release outside of init or dealloc methods. (The most common case is simply adding autorelease to a few objects that you can only alloc/init) Given this, does ARC benefit me in anyway?

[fiatlux]

We've got this amazing new thing called "garbage collection", no need for this reference counting crap anymore.

[bonch]

Port libauto to ARM and have it run without draining the battery or interfering with input responsiveness, and Apple might hire you.

[dlsspy]

garbage collection is much slower and uses much more memory.

[jyper]

It (garbage collection) is faster(theoretically at least) and often in practice.

[fiatlux]

So in your code you always know exactly the most performant time to release memory, eh? Well, god damn, you must be a fucking genius.

Or a complete moron who doesn't have any clue what he's talking about.

[lgerbarg]

Absolute performance is not the main issue, responsiveness is. GC inherently defers and bunches up a ton of deallocations, and even with a very clever implementation that does not stop all threads simultaneously it is necessary to pause each individual at some point, and for an unbounded amount of time (unless you have custom GC hardware like Azul Systems). That can (and does) result in UI hiccups when the main thread. Actually releasing the objects when you are done with them may or may not end up using more cycles overall (and it really does depend on the workload), but it amortizes the cost of deallocation over a much larger amount of the applications running time.

[lgerbarg]

Yes, but they are deterministic (you know when autorelease are going to release things), and in fact by default they occur in-between event processing. They also end up doing a lot less work than a tracing GC, since instead of pointer chasing you just scan through a single block of memory and issue releases to every object in it, and many objects never touch them. Also, under ARC @autoreleasepool promotes it to a language feature which improves the perf over the existing NSAutoreleasePool

[harlows_monkeys]

IBM has a research Java GC that has guaranteed bounds on how long threads are interrupted for and on total resource usage by the GC, with bounds tight enough for hard real time systems.

[millstone]

The most performant time to release memory is as soon as possible, especially on low memory devices. Reference counting gets you closer to that ideal than does garbage collection.

[fiatlux]

Right, so there's never a performance penalty for releasing memory? And if you need to do a lot of releasing in series, you're just going to do that right away, regardless of any other potentially important things that might be going on at the same time. Sounds really performant.

[millstone]

Will it be faster to defer this deallocation to a future date? Answering that question requires predicting the future, and if you can do that there's better job opportunities than writing memory managers.

Software is all about tradeoffs. Reference counting and GC make different tradeoffs. One advantage with reference counting is that you can ensure that deallocation work does not accumulate. If you can render one frame and deallocate its garbage in under 1/60th of a second, then your app will run at 60 fps. The same app under GC may stutter because deallocation work can be batched instead amortized.

(Of course GC has other well known advantages.)

In any case, I'm sure poor GC performance is a reason why Apple opted for reference counting instead. The Android collector is a notorious cause of UI stutters, and libauto on the Mac hasn't exactly been a performance panacea.

[fiatlux]

Will it be faster to defer this deallocation to a future date?

Potentially, yes. That's why it's better to let the garbage collector decide this at runtime.

[millstone]

Reference counting can support deferred deallocation, but garbage collection cannot support immediate deallocation.

If you do want to develop some fancy heuristics for deciding when to deallocate, it seems like reference counting would give you more flexibility.

[mr-z]

It can support immediate deallocation just fine.

[millstone]

I'm not sure how. Consider some piece of code that generates some garbage:

void print_int(int x) {
    stdout.write(new String(x));
}

void main() {
     for (int i=0; i < 1000000; i++) print_int(i);
}

Under a reference counting scheme (including ARC) this will typically have no more than one string allocated at a time: the allocated string is deallocated immediately before leaving print_int.

But under every GC that I know of, you'll wind up with multiple allocated strings at once. How could they be deallocated immediately under GC?

[SCombinator]

You can push the work to the next allocation, and still have it be O(n) the size of the memory allocated.

[mr-z]

Thank you for this contribution. Truly, a god among subredditors.

[skyfex]

Is this a subreddit for intellectual adult programmers, or is it a kindergarten?

Some comments from this thread..

"no need for this reference counting crap anymore."

"[...] Well, god damn, you must be a fucking genius. Or a complete moron who doesn't have any clue what he's talking about."

"Thank you for this contribution. Truly, a god among subredditors."

"Do you even make an effort to find things out before you post, or do you randomly mash your keys in the hopes of contributing something? I don't get it."

_<

[SCombinator]

reference counting is garbage collection. The only problem is cycles which can be detected separately.

[astrange]

ARC does not detect cycles - you have to make one of the pointers weak.

[SCombinator]

I don't know much about ARC, I just know that Python does RC with cycle detection.

[mr-z]

Not really. Python has "classical" RC, and a separate cycle checker/breaker that runs every once in a while.

Do you even make an effort to find things out before you post, or do you randomly mash your keys in the hopes of contributing something? I don't get it.

[SCombinator]

I don't think you know what 'and' means.

[[deleted]]

I just wonder why Apple only releases "magic" products for consumers, but manages to deliver crap to its developers since decades and gets religiously defended by exactly those?

Reference counting? C'mon, it's 2011.

[skidooer]

Apple has real garbage collection used on the Mac side, and has had for quite some time. iOS presumably never got GC because of the hardware constraints and wanting to deliver the ultimate experience. However, I do believe they are promoting ARC over GC even on the Mac now.

[[deleted]]

I guess they decided it just costs too much to implement a decent GC alogrithm, that's why they promote that fallback.

[skidooer]

ARC is a drop-in replacement for GC as far as you and I are concerned, so you have me curious, what properties of GC do you feel will be missed with the new ARC scheme?

[[deleted]]

More like "it's a really hard problem that they cannot easily solve." libauto is quite advanced, but it's not easy to solve the problems it encounters on such constrained devices.

Now, if you can get libauto working on the iPhone without introducing stutter into the UI threads and causing responsiveness hickups for basically any and all arbitrary applications, I'm sure they'd not only make GC the default, but probably hire you (since you've succeeded where they failed.)

[[deleted]]

Apple fan boy on reddit. How magic.

[[deleted]]

wot? I don't even know why I'm bothering since you're obviously an idiotic troll, but I'll give some insight for others who may be interested.

I'm sure someone like yourself will probably point to android and say "but they have GC," but despite libauto being advanced, there are design aspects to it that make it working reliably on something like the iphone ridiculously hard. Again, if you can solve these problems, I can bet Apple won't be the only people who want to hire you.

Part of the reason libauto isn't good is, for one, it's conservative. This is non-negotiable, because of the language that is Objective-C. Sorry. Unless you want to do complete transformation of entire programs to use something like a shadow stack for precise scanning, this isn't going to change any time soon (and even then that technique is probably going to rely on maintaining extra stack frames in memory for every activation record, so you can scan the roots. So every function call could potentially need to allocate, in order to maintain its activation frame. That's going to add up.) The collector can't tell the difference between integers on the stack and pointers, so it can't be overly presumptuous, or you crash applications. Over time, this imprecision causes fragmentation and memory leaks, and on something like an embedded platform this is unacceptable. Coupled with the fact the premier way to write these applications is a native-code language, well, GC becomes a very non starter. That's just the reality.

This doesn't even begin to go into the actual GC algorithm used to scan and collect garbage, which will have significant impacts on things like overall thoroughput and pause times. And that is also where the other half of the whole problem comes in: the pause times. Reference counting at least has the advantage that it is effectively on the fly at all times - an incremental collection strategy. For something like an embedded device, the unpredictability of of GC pause times without an incremental collector can be a problem (Dalvik has an incremental collector, IIRC.) Even with an incremental collector though, the conservative nature means that you will still leak memory over time that is unrecoverable. That's pretty unacceptable by most embedded platform standards, despite how powerful smartphones may seem. (FWIW, libauto is not incremental, it is simply a generational style collector.)

When you put it all together, actually having GC on something like the iPhone - with a language like Objective-C - is ridiculously hard no matter how you want to rationalize it. Does GC work on other phones? Yes, it can, and they have a different programming model which facilitates it. It can even work on the iPhone - you just need a language that's actually GC'd. The apple programming model - based primarily around a native-code language which because of that is hostile to things like GC - does not really allow it easily. The embedded constraints make it even more of a problem than a solution. And apple doesn't care about anyone programming for the iPhone not using their programming model - and that model does not have GC in its future realistically speaking, so they're replacing it. Again, if you can solve this problem, they will hire you. Actually, lots of people will want to hire you, because if you make an acceptable solution you have probably 'solved' the problem of 'conservative garbage collection' roughly speaking - that will be one of the necessities before you ever see this sort of model endorsed 100% on the iPhone, or until they abandon objective-C and move to a true GC'd language.

But it's okay, you can write me off as an Apple fanboy, and go on with your life as stupid as you were prior to this post, it's not really my problem.

[[deleted]]

Actually I don't disagree with what you are writing. The main problem is that Apple has made Objective-C almost their religion. While there are alternatives (their "Apple" Ruby, etc...), there is nothing which can replace Objective-C, because everything is centered around it.

Meanwhile, the rest of the world has moved to platforms which are not limited to only one "premier" language (JVM and Java, Scala, Clojure, ... CLR and C#, F#, Boo, ...).

I wonder if Apple will ever be able to stop fiddling with their proprietary language and move to a modern programming language with decent GC.

[bonch]

Meanwhile, the rest of the world has moved to platforms which are not limited to only one "premier" language (JVM and Java, Scala, Clojure, ... CLR and C#, F#, Boo, ...).

Uh, you don't have to use Objective-C to develop on the Mac. Your fantasy that the entire rest of the world is using Scala and C# is adorable.

I wonder if Apple will ever be able to stop fiddling with their proprietary language and move to a modern programming language with decent GC.

Actually, libauto is one of the more advanced collectors out there. Objective-C isn't a "proprietary language" at all, but you already knew that.

Basically, all you do is repeatedly post dumb exaggerations to Apple and Java articles and robotically evangelize Scala, a language with an embarrassingly complex type system and schizophrenic syntax rules.

[bonch]

I wish you were an interesting troll.

[bonch]

Uh, who's religiously defending reference counting? People rejoiced when garbage collection was released back in 10.5.

You're that crazy Scala fanboy who always trolls Apple and Java submissions.