Automatic Reference Counting

[Jiva DeVoe]

FYI...

http://clang.llvm.org/docs/AutomaticReferenceCounting.html

This means we can officially talk about it... now that it's public and OS.

So... ARC... if choosing between ARC and GC... I'd say ARC all the way... would you guys agree?

[Brad Miller]

One thing to clarify, we can talk about the language and compiler aspect of it now. Use of features relating to it in versions of Xcode, Lion, or iOS5 that may or may not exist are still under NDA and can't be talked about. So everyone please keep it on the good side of the line.

Brad Miller
br...@cynicalpeak.com
http://cynicalpeak.com/

[Jiva DeVoe]

What's Lion and iOS 5? I've never even heard of those...

I can neither confirm nor deny that any such feature exists in any location other than the LLVM docs. ;)

> --
> You received this message because you are subscribed to the Google Groups "XCodePhoenix" group.
> To post to this group, send email to xcodep...@googlegroups.com.
> To unsubscribe from this group, send email to xcodephoenix...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/xcodephoenix?hl=en.
>

[Brent Rowland]

Delphi 3, back in the late 90's, had automatic reference counting for dealing with COM, later known as ActiveX.

We commend Apple for yet another brilliant invention!

Seriously, if it makes the code more succinct without incurring noticeable GC lag and perhaps unacceptable memory overhead on mobile devices running hypothetical operating systems, bravo.

I would be curious, however, to see actual numbers for real programs doing real work when compiled for GC or with ARC. I spent too many years as a static language, manual memory management bigot, only to have my eyes opened finally by languages that were quite fast enough for most of the programs I needed to write. Now I like to see numbers.

However, I would also love to hear developer impressions contrasting the experience of writing for both systems. IS there any appreciable difference between coding with GC and with ARC? Either one gets rid of the reference counting "noise" in the code, which isn't that hard to type but must be scanned by your eyes every time you look at a method.

Brent

On Jun 15, 2011, at 4:41 PM, Jiva DeVoe wrote:

[Troy Anderson]

ARC is not GC nor does it eliminate reference counting. It just eliminates your need to take care of it yourself. The compiler inserts the retain/release messages in the appropriate places and optimizes out any redundant ones. The result is that you get the benefits of manual memory management without the pain of actually managing it manually, all without any GC.

-Troy

[Jiva DeVoe]

To be clear, no one said they invented it. Python does ARC, Ruby does ARC, lots of languages do ARC. When they introduced GC for Objective-C I was wishing it was ARC, cuz GC kinda stinks due to non-deteminitivism.

I too generally prefer manual memory management due to the curse of GC. Suspect we'll have to wait until it's actually in the wild to see real numbers, but I bet it'll be good.

WRT the code, yes, obviously, you can get rid of your releases, your retains and your autoreleases, you also need to now think in terms of strong references vs weak references. Strong being essentially your traditional retained variables and weak being the equivalent to your old assign properties. The default for all variables is to be strong references... that is, they'll be retained until no one refers to them anymore. If you define a variable as weak, however, it will not be retained. This is important for delegates and so forth. All variables also are now initialized to nil by default and weak references will also be nilled when deallocated. The modifiers used to define your variables are __strong and __weak.

Speaking of variables... when talking about ARC and variables... ARC only affects Objective-C objects. It does not impact any C level pointers allocated with malloc or anything like that.

There's also an additional modifier of __unsafe_unretained which is like weak, but is not zeroed when deallocated.

Variables returned through a parameter that must be autoreleased can also use an __autorelease storage modifier. Mainly you'd use this in cases where you might be doing something like returning an NSError ** or something.

ARC also adds a language construct of @autoreleasepool which works similarly to @synchronized or @try/@catch. It allows you to define a block of code which has it's own autorelease pool.

I suspect for those of us who are used to doing manual memory management, we'll have a lot of discussion about where ARC is inserting it's releases and retains... I think this is interesting from a "this is how it works" perspective... I'm not sure if that'll be helpful or harmful in terms of learning it though, since at the end of the day, you'll want to probably forget about retain and release and change your thinking to strong/weak/autoreleased.

On Jun 15, 2011, at 5:52 PM, Brent Rowland wrote:

[Brad Miller]

What Troy said. It's not GC, it's optimized manual memory management that's being done automatically for you. With some of the optimizations that the compiler can do safely that we can't, it's actually faster. We can't talk about some of the benchmarks that were shown, but Jonathan converted TouchJSON to arc. He tweeted:

FLOORED. Completely & utterly floored. TouchJSON benchmarks: 2000000 iterations. Old code. 22.5846 secs. ARC code: 16.9997 secs

Now, you're not always going to see that much of a speed-up. TouchJSON is friendly for some of the optimization that can be done since it has very heavy accessor use due to parsing and storing the values. But it does show what can happen.

I think I've mentioned once or twice in the past that I hate GC and won't touch it with a 10 foot pole. I'm fully embracing ARC and it will be used everywhere once it's feasible.

Brad

Brad Miller
br...@cynicalpeak.com
http://cynicalpeak.com/

[Brent Rowland]

Actually, Ruby uses mark-and-sweep garbage collection. Python uses ARC
plus an extra collector for orphaned object cycles.

My jab at Apple was primarily because of the list of "innovations"
announced recently that duplicate the accomplishments of their
ecosystem after only recently scolding Samsung for being such a
copycat.

I find it regrettable that now Apple has 3 different memory management
systems in the language. One of the things I hate about Delphi is the
accumulated crud it's dragging around and the associated
inconsistencies. Of course, Objective-C has its C legacy too, but
sometimes it's possible to ignore the worst parts of that or wrap it
up nicely.

I love the automatic nilling of weak references. I dunno how expensive
that is, but it smells like great engineering along the lines of
non-fragile instance variables!

Brent

[Brad Miller]

Automatic nilling of weak references isn't anymore expensive than doing it manually. So the only way it'll cost you is if you're a bad programmer and not nilling them out already. Your crashes magically going away will off set that pain though.

Obj-c does have the 3 memory models right now, but in a practical sense it's only going to be one. There's no good reason to be using GC at this point and I wouldn't be shocked to see it deprecated in the next couple of years. While I don't think they'll get rid of the current manual memory system, it's use will drop down to niche uses. For the majority of your project you'll use ARC and maybe turn it off for manual if you find some weird edge case.

Brad

Brad Miller
br...@cynicalpeak.com
http://cynicalpeak.com/

[Seth]

Why did they introduce GC first, and wait to introduce ARC until later?

On Wed, 15 Jun 2011 19:05 -0700, "Brad Miller" <brad...@gmail.com>
wrote:

Seth
sd...@cornell.edu

[Brent Rowland]

The biggest reason I was hoping for the wide adoption of GC was that MacRuby depends on it. While MacRuby can "easily" piggyback on top of GC, it's not clear that ARC would help at all, depending as it does on a sophisticated compiler analyzing code rather than a runtime tracing object graphs.

Anyone know where in the LLVM stack the ARC logic lives?

Brent

Sent from my iPad

[Brad Miller]

Compilers. This is another new thing that Apple's been able to add thanks to LLVM. The infrastructure allows for it whereas the mess that is GCC didn't. GC is mainly a runtime item and not a compiler thing. So Apple was able to add it without having to do the major changes that something like ARC requires.

It was also pre-iPhone that it was developed. I remember hearing about them working on GC back as far as WWDC 2003. So there might have been a little bit of thinking that the GC overhead didn't really matter on the desktop.

Brad

[Brian Webster]

On Jun 15, 2011, at 8:42 PM, "Seth" <sd...@cornell.edu> wrote:

> Why did they introduce GC first, and wait to introduce ARC until later?

Most likely because they didn't yet have the compiler technology (LLVM and Clang) that would allow them to implement it soundly. ARC is built on top of the same logic used by the static analyzer, which can already warn you about potential memory leaks in manually managed memory.

--
Brian Webster
bweb...@mac.com

[Robert Cober]

i just finished porting a decent part of my game toolkit to arc.

it mainly consisted of removing release and super dealloc- but was
still a long effort.

At one point i almost stopped because the initial number of errors and
warni gs was daunting, but i slogged through it.

Now its actually working!!!!

so far i am impressed with stability - havent checked performance or
memory usage

will post when i do

Robert Cober
http://casualdistractiongames.com

> >>> For more options, visit this group athttp://groups.google.com/group/xcodephoenix?hl=en.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups "XCodePhoenix" group.
> >> To post to this group, send email to xcodep...@googlegroups.com.
> >> To unsubscribe from this group, send email to xcodephoenix...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/xcodephoenix?hl=en.

>
> > --
> > You received this message because you are subscribed to the Google Groups "XCodePhoenix" group.
> > To post to this group, send email to xcodep...@googlegroups.com.
> > To unsubscribe from this group, send email to xcodephoenix...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/xcodephoenix?hl=en.
>

> Brad Miller
> b...@cynicalpeak.comhttp://cynicalpeak.com/

[Robert Cober]

BTW - I an getting a
warning: -fobjc-arc is not supported with fragile abi

On the release builds using arc???

Thanks in advance for any thoughts or feedback on this....

On Jun 16, 5:55 am, Robert Cober <bobco...@gmail.com> wrote:
> i just finished porting a decent part of my game toolkit to arc.
>
> it mainly consisted of removing release and super dealloc- but was
> still a long effort.
>
> At one point i almost stopped because the initial number of errors and
> warni gs was daunting, but i slogged through it.
>
> Now its actually working!!!!
>
> so far i am impressed with stability - havent checked performance or
> memory usage
>
> will post when i do
>

> Robert Coberhttp://casualdistractiongames.com

[Brad Miller]

Are you targeting an OS < 4.3? If you're not, did you use __weak? It's not supported on iOS4.

Brad

[Robert Cober]

I am using __weak in a couple places.

I am only getting the warnings when building a release build targeting
mac 64-bit.

(I have a project with both mac and iOS targets )

First noticed when building a profile scheme which had the release
build set.

It runs ok - should I be worried about it?

What does fragile abi mean ?

[Brian Webster]

On Jun 16, 2011, at 12:52 PM, Robert Cober wrote:

> I am using __weak in a couple places.
>
> I am only getting the warnings when building a release build targeting
> mac 64-bit.
>
> (I have a project with both mac and iOS targets )
>
> First noticed when building a profile scheme which had the release
> build set.
>
> It runs ok - should I be worried about it?
>
> What does fragile abi mean ?

The non-fragile ABI allows for things like changing the ivars of a superclass without breaking already compiled subclasses (among other things). It's only supported on 64-bit on the Mac though, because of backwards compatibility concerns which didn't allow them to support it on existing 32-bit architectures.

I'm betting your release build is probably set to build universal as 32 and 64 bit (unlike debug, which typically only compiles the native architecture of your dev machine, i.e. 64-bit only), so that may explain why it's complaining at you now that you've changed to doing a release build. If you want to use ARC on the Mac, I'm pretty sure you'll have to drop 32-bit support to do so. You can change the targeted architectures in the build settings for your target in Xcode.

--
Brian Webster
bewe...@gmail.com

[Brad Miller]

Yeah, what he said. 32-bit is dead now on the mac. Really only effects a couple models that are 6 years old now.

Also if you're targeting 10.6 or iOS4 you need to change the __weaks to __unsafe_unretained and remember to zero out your references in dealloc like you always have.