I am a new cocoa developer coming from a C#/Java background. I had been introduced to memory management patterns which objective-c language uses and I just find them very helpful for code-conscious development.
Why does Apple now want us to use ARC (Automatic Reference Counting) instead of MRR (Manual Retain-Release) and what advantages other than time saving does ARC offer?
I see such a transition negatively affecting good-citizen habits that developers gain from the obj-c ecosystem.
Nick
It's unfortunate that making it easier for competent developers to be correct has a side effect of making it easier for new developers to not learn, but it seems like it's probably worth it.
ARC is less forgiving than a tracing collector like C# or Java use though. If you don't have a clear object ownership model you will almost certainly create cycles and leak tons of memory. My hope would be that this is made obvious enough (via Instruments? That still requires seeking it out... not sure what could be done here) that new developers will quickly learn to keep their object graph clear and acyclic.
ARC allows me to concentrate on writing useful code instead of boilerplate dealloc methods.
Most people I know have used autorelease behind every alloc anyway, because it saved you a release later and you couldn't forget to actually put it. So the object was around until the autorelease pool was drained, and with ARC the object gets deallocated when it isn't needed anymore. I think in those cases the ARC-compiled program will even use less memory.
And, shame on me, it helps me to make my apps crashing less often too.
That premature release that happens every 10.000 launches. The one that I could never track down completely, hopefully with ARC this is a thing of the past.
I see such a transition negatively affecting good-citizen habits that developers gain from the obj-c ecosystem.
probably in the same way an embedded developer who started with assembler thinks people that start with C and have never used assembler get into bad habits.
In my opinion the MRR vs ARC discussion is similar.
ARC and C both allow to write more maintainable code in a shorter time.
And both of them can lead to a larger memory and cpu footprint.
If I remember correctly Apple announced that they did add a little speed up to retain and release to compensate that impact on cpu usage. And because of that there is no real reason that MMR is still around.
I, for one, welcome our new ARC overlords.
i've actually rather enjoyed moving to ARC - it's one less thing to think about. on top of that, i think newcomers would often be tripped up by the significance of naming conventions (+alloc, -copy etc vs [NSString stringWith....]). the only tricky bit is when you start dealing with CoreFoundation etc (the C APIs) where you still have to keep in mind just who is owning what.
Related
I'm reading a book on Objective C, and I was wondering about 2 things:
1.Should I take the time currently to read a whole chapter on memory management since we mostly use ARC?(only asking this question to make sure im managing time properly)
2.If you are doing a really good job on manual management, can you get to better performance than using ARC? (like that your app will work faster)
tnx
You should at least familiarize yourself with the basic concepts of the manual memory management, because ARC uses it under the hood. You need to learn at least about three things: retain, release, and autorelease. This will help you understand discussions about ARC's inner working.
ARC is mostly a compiler trick (with some support from the runtime). You can write less code, but you cannot get better performance from it. Essentially, ARC lets you deal with memory management declaratively, while the manual management uses imperative style. However, both systems call the same methods from the runtime.
1、Of course you should.ARC is based on the same memory management,just let the compiler do the same work.If you want to master a kind of technology，try to know how does it work is a faster way.
2、Actually,they do the same performance.Just let the compiler do what did you do before.For when you retain an object(which is a property) in the class, we always release in the dealloc.you alloc an object in a method,assign to local pointer,it will be release when the stack memory of this method clean up;if you retain it in the method to the method's local variable you release it in the same place.Then you will be find they are all predictable.why not let the machine do it?
According to Apple's ARC Documentation, there are a fairly significant number of changes to the way that one develops software when using ARC.
As a complete beginner to Objective-C, would it be better to start off with ARC disabled, with the idea that it would give me a better low-level understanding of what is going on behind the scenes? Or has ARC essentially deprecated the 'old way' of doing things, to the point that it's not really worth spending time learning?
This is basically an opinion question, and is therefore fairly dangerous.
My Opinion is a qualified yes. It is worth learning basic memory management. The qualification being don't get bogged down in it. Learn what ARC is doing for you under the hood with some very simple projects. Once you have a basic understanding of how to handle memory management, i.e. how to avoid retain cycles(as jemmons alluded to they can still be a problem with ARC).
Once you have a basic grasp of memory management. Start using ARC.
Also as Jason Coco pointed out ARC handles memory management for (to put it simply) NSObject subclasses. So all of the CF Objects you will still be handling yourself, if you need to use them.
An excellent explanation about what ARC is doing for you under the hood can be found in the WWDC2011 Session 323 - Introducing Automatic Reference Counting.
But there are some other considerations that might steer your decision.
What devices do you need to target?
If you plan to target iOS 4.3 and up ARC effectively handles memory management for you.(of NSObject subclasses)
If you plan to target iOS 4.2 then you will not be able to use weak references(you will use unsafe_unretained). iPhone 3g? & iPod touch 2nd gen are stuck at this OS level, because there are many of these devices still in service many developers are still targeting them.
If you plan to target iOSs earlier than 4.2(This would be rare) you will definitely need to learn MRC(Manual Reference Counting).
If you plan to build Mac Apps, there is a garbage collector available on that platform. ARC is also an option(full ARC 10.7, no weak support 10.6).
It's worth noting that ARC is checked by default when you start a new project in Xcode. This is as good a sign as any that the old retain/release way of doing things is deprecated and Apple sees ARC as the future. Your first lesson as a new ObjC developer might be that it never pays to swim up-stream against Apple.
Also, while it's fairly easy to convert old retain/release samples to ARC (for the most part, just drop any retains, releases, and autoreleases), the inverse is not true. And I've already seen a lot of sample code cropping up that's written ARC-style. So as someone just starting out, it'd pay more to learn the ARC way.
Note this doesn't mean you don't have to understand reference counting. It's still an important part of an object's life cycle and you still need to be aware of such things (if only to know when to use weak or strong references). But when it comes time to write code, write it with ARC on.
The "old" style is simply just reference counting to manage your object's lifetime. There's not really all that much too it, but it can be error-prone and cause all kinds of grief. If you're just starting, I'd personally suggest you just learn to program using ARC. You'll still get to deal with reference counting when you need to use the C-library objects, like CoreFoundation or CoreGraphics.
Apple itself recommends ARC for new projects.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html#//apple_ref/doc/uid/10000011i
read point 2 in At a Glance
There is sooo much more interesting to learn in Objective C & iOS apart from the memory management.
My advice : Don't bother about MRR
It would be a great idea just to go over it and understand what's going on, but for development it's not essential, and as you can see most if not all developers have moved their deployment targets to iOS 5.0+, so you are likely not to develop under manual reference counting.
However if you plan to use non ROP -retainable object pointers- in your code like CFStringRef, you might want to really look at non ARC so you can understand things like bridge, because you can combine ARC and non ARC code in one project.
Looking at the release notes of OS 10.7, there's some stuff about using Automatic Reference counting (ARC) to make memory management simple. I'm about to embark on a new Cocoa project soon and wondered whether it would be worth using the model (the way I understand it, you can't mix between using ARC and not using it)?
The dilemma seems to be using something new versus using something that could potentially save lots of debugging time later. But is that the case? Has anyone played around with it and found no real-world benefit?
Without a doubt you should use ARC. ARC injects the retain release calls at the most appropriate times, so you may actually see lower average memory use than you would if you didn't use ARC.
I have used ARC and it is immensely powerful. You stop having random crashes and your app just feels more responsive. As they said at WWDC, there is no reason not to use Automatic Reference Counting.
Also, you can use non-ARC files in the same project as ARC files.
I agree with FreeAsInBeer about using ARC. However, it should also be made clear that garbage collection (GC) should not be used. It looks like Apple is henceforth going to focus their efforts ARC, while letting GC die a slow death. This is wonderful because ARC is clearly a far superior technology, whereas GC is slow and extremly buggy.
So yes. Use ARC. Stay away from GC.
Can someone briefly explain to me how ARC works? I know it's different from Garbage Collection, but I was just wondering exactly how it worked.
Also, if ARC does what GC does without hindering performance, then why does Java use GC? Why doesn't it use ARC as well?
Every new developer who comes to Objective-C has to learn the rigid rules of when to retain, release, and autorelease objects. These rules even specify naming conventions that imply the retain count of objects returned from methods. Memory management in Objective-C becomes second nature once you take these rules to heart and apply them consistently, but even the most experienced Cocoa developers slip up from time to time.
With the Clang Static Analyzer, the LLVM developers realized that these rules were reliable enough that they could build a tool to point out memory leaks and overreleases within the paths that your code takes.
Automatic reference counting (ARC) is the next logical step. If the compiler can recognize where you should be retaining and releasing objects, why not have it insert that code for you? Rigid, repetitive tasks are what compilers and their brethren are great at. Humans forget things and make mistakes, but computers are much more consistent.
However, this doesn't completely free you from worrying about memory management on these platforms. I describe the primary issue to watch out for (retain cycles) in my answer here, which may require a little thought on your part to mark weak pointers. However, that's minor when compared to what you're gaining in ARC.
When compared to manual memory management and garbage collection, ARC gives you the best of both worlds by cutting out the need to write retain / release code, yet not having the halting and sawtooth memory profiles seen in a garbage collected environment. About the only advantages garbage collection has over this are its ability to deal with retain cycles and the fact that atomic property assignments are inexpensive (as discussed here). I know I'm replacing all of my existing Mac GC code with ARC implementations.
As to whether this could be extended to other languages, it seems geared around the reference counting system in Objective-C. It might be difficult to apply this to Java or other languages, but I don't know enough about the low-level compiler details to make a definitive statement there. Given that Apple is the one pushing this effort in LLVM, Objective-C will come first unless another party commits significant resources of their own to this.
The unveiling of this shocked developers at WWDC, so people weren't aware that something like this could be done. It may appear on other platforms over time, but for now it's exclusive to LLVM and Objective-C.
ARC is just play old retain/release (MRC) with the compiler figuring out when to call retain/release. It will tend to have higher performance, lower peak memory use, and more predictable performance than a GC system.
On the other hand some types of data structure are not possible with ARC (or MRC), while GC can handle them.
As an example, if you have a class named node, and node has an NSArray of children, and a single reference to its parent that "just works" with GC. With ARC (and manual reference counting as well) you have a problem. Any given node will be referenced from its children and also from its parent.
Like:
A -> [B1, B2, B3]
B1 -> A, B2 -> A, B3 -> A
All is fine while you are using A (say via a local variable).
When you are done with it (and B1/B2/B3), a GC system will eventually decide to look at everything it can find starting from the stack and CPU registers. It will never find A,B1,B2,B3 so it will finalize them and recycle the memory into other objects.
When you use ARC or MRC, and finish with A it have a refcount of 3 (B1, B2, and B3 all reference it), and B1/B2/B3 will all have a reference count of 1 (A's NSArray holds one reference to each). So all of those objects remain live even though nothing can ever use them.
The common solution is to decide one of those references needs to be weak (not contribute to the reference count). That will work for some usage patterns, for example if you reference B1/B2/B3 only via A. However in other patterns it fails. For example if you will sometimes hold onto B1, and expect to climb back up via the parent pointer and find A. With a weak reference if you only hold onto B1, A can (and normally will) evaporate, and take B2, and B3 with it.
Sometimes this isn't an issue, but some very useful and natural ways of working with complex structures of data are very difficult to use with ARC/MRC.
So ARC targets the same sort of problems GC targets. However ARC works on a more limited set of usage patterns then GC, so if you took a GC language (like Java) and grafted something like ARC onto it some programs wouldn't work any more (or at least would generate tons of abandoned memory, and may cause serious swapping issues or run out of memory or swap space).
You can also say ARC puts a bigger priority on performance (or maybe predictability) while GC puts a bigger priority on being a generic solution. As a result GC has less predictable CPU/memory demands, and a lower performance (normally) than ARC, but can handle any usage pattern. ARC will work much better for many many common usage patterns, but for a few (valid!) usage patterns it will fall over and die.
Magic
But more specifically ARC works by doing exactly what you would do with your code (with certain minor differences). ARC is a compile time technology, unlike GC which is runtime and will impact your performance negatively. ARC will track the references to objects for you and synthesize the retain/release/autorelease methods according to the normal rules. Because of this ARC can also release things as soon as they are no longer needed, rather than throwing them into an autorelease pool purely for convention sake.
Some other improvements include zeroing weak references, automatic copying of blocks to the heap, speedups across the board (6x for autorelease pools!).
More detailed discussion about how all this works is found in the LLVM Docs on ARC.
It varies greatly from garbage collection. Have you seen the warnings that tell you that you may be leaking objects on different lines? Those statements even tell you on what line you allocated the object. This has been taken a step further and now can insert retain/release statements at the proper locations, better than most programmers, almost 100% of the time. Occasionally there are some weird instances of retained objects that you need to help it out with.
Very well explained by Apple developer documentation. Read "How ARC Works"
To make sure that instances don’t disappear while they are still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance. ARC will not deallocate an instance as long as at least one active reference to that instance still exists.
To make sure that instances don’t disappear while they are still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance. ARC will not deallocate an instance as long as at least one active reference to that instance still exists.
To know Diff. between Garbage collection and ARC: Read this
ARC is a compiler feature that provides automatic memory management of objects.
Instead of you having to remember when to use retain, release, and autorelease, ARC evaluates the lifetime requirements of your objects and automatically inserts appropriate memory management calls for you at compile time. The compiler also generates appropriate dealloc methods for you.
The compiler inserts the necessary retain/release calls at compile time, but those calls are executed at runtime, just like any other code.
The following diagram would give you the better understanding of how ARC works.
Those who're new in iOS development and not having work experience on Objective C.
Please refer the Apple's documentation for Advanced Memory Management Programming Guide for better understanding of memory management.
I've long considered myself a garbage collection snob – despite a secret love for C++, I find myself sneering at developers who actively choose to use languages without (read: missing) garbage collection when they're given the option.
And then I met Objective-C. Wow! Its system of reference counting seems brilliantly simple – I'd even go so far as to say elegant. When developing for OSX, developers are given the option to use a snazzy GC; when developing for iOS, developers are stuck with reference counting.
My question is:
If I am developing an OSX application that could potentially be ported to iOS, is Objective-C's reference counting system time-consuming enough (development-wise and bug-fixing-wise) to warrant ignoring it for the application's first version?
What problems am I likely to run into if I rely on reference counting*, assuming I'm not clever enough to construct any diabolically complex cyclical data structures? With features like autorelease, it all seems so easy, but I know that Apple wouldn't have invested the effort into creating a garbage collector if this were really the case. What should I be on the lookout for?
* I am aware that I can use the garbage collector even if I am throwing around retains and releases (they'll be ignored). However, considering non-GC applications often use RAII, I don't understand how that would work if a generational GC were to "replace" calls to retain and release. Wouldn't resources potentially be released late?
My experience with developing code to port to iOS is that taking GC only code and back porting it to reference counting is a bit tedious and time consuming and potentially error prone. Having said that, as long as you use properties (make them retain even though it makes no difference in GC) as much as possible and you enable the static analyser build phase, it's not too bad. The static analyser will catch most failures to observe the memory management rules. It won't notice if you fail to release an ivar in dealloc, but you can go through and systematically add all the dealloc methods.
Bear in mind that you can't directly port a Mac application to the iPhone, the VC part of MVC has to be completely rewritten, so you could take the approach of writing the Mac UI solely for garbage collection and only make the model classes compatible with both GC and reference counting.