PDA

View Full Version : How reliable is garbage collection in Objective-C




ZVH
Apr 14, 2012, 07:51 PM
I've heard it wasn't, yet others seem to swear by it.

One guy told me GC would prematurely mark and collect on class variables without warning. I haven't been able to confirm or deny it. He was referring to this type of allocation:

[NSString stringWithFormat:@"%@", @"This is a test"];

versus

[[NSString alloc] initWithFormat: @"%@", @"This is a test"];

He told me the first example could be prematurely collected, as in before it even gets used, whereas the GC would handle the second example properly.

I'm considering switching to a GC environment for development, but not if it's buggy.

Comments anyone?



lloyddean
Apr 14, 2012, 11:14 PM
You may wish to forget Garbage Collection and, depending upon your platform requirements, use Automatic Reference Counting instead.

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

xStep
Apr 14, 2012, 11:30 PM
The only odd thing mentioned that I could find was from the Garbage Collection Programming Guide (https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcAdoption.html%23//apple_ref/doc/uid/TP40002457-SW1). Under disadvantages it says, "A common design pattern whereby resources are tied to the lifetime of objects does not work effectively under GC". I'd like a better explanation than that.

There are three memory management techniques; manual memory management (http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html) where you handle the retains and releases, garbage collection (GC (https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html%23//apple_ref/doc/uid/TP30001223-CJBGIAGF)) where the runtime takes care of releases, and the new automatic reference counting (ARC (https://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html%23//apple_ref/doc/uid/TP40011226)) where the compiler balances the retains and releases.

CG and ARC should not be prematurely releasing objects.

In your sample lines, you need to understand that the first does not return a retained object. The life of that object is guaranteed to last to the end of the method it is in. In the second line, the alloc causes a retain. If you assigned the returned value (an object id) of the first line to an instance variable, you'll need to add your own retain to keep it around longer than the call to the method. If you don't do that, the object will disappear upon the next cycle of releasing the memory associated with it. The second line will require a release by you under manual memory management, or the garbage collection will do it if you are using that.

The GC method wasn't a big hit with developers from what I could tell and does not work with iOS. The new ARC method is what developers are moving to, usually away from the manual method.

JoshDC
Apr 15, 2012, 10:17 AM
I would strongly discourage moving to garbage collection. The fact that iCloud isn't supported in garbage collected applications should raise questions about its future. From the programming guide:

Not all frameworks and technologies support garbage collection; for example, iCloud is not supported in applications that use garbage collection.

Also: https://news.ycombinator.com/item?id=3603218.

Catfish_Man
Apr 15, 2012, 04:01 PM
I've heard it wasn't, yet others seem to swear by it.

One guy told me GC would prematurely mark and collect on class variables without warning. I haven't been able to confirm or deny it. He was referring to this type of allocation:

[NSString stringWithFormat:@"%@", @"This is a test"];

versus

[[NSString alloc] initWithFormat: @"%@", @"This is a test"];

He told me the first example could be prematurely collected, as in before it even gets used, whereas the GC would handle the second example properly.

I'm considering switching to a GC environment for development, but not if it's buggy.

Comments anyone?

So, first off, what everyone else said: don't use GC. ARC killed it. Seriously, don't use it.

That said, what he's probably talking about is things like this:

void *bytes = [someNSData bytes];
[self doSomethingWithSomeBytes:bytes];

Because 'someNSData' is not referenced after the first line, if that's the only live reference to it, it may be collected... *even though* bytes is a pointer to inside of it. This isn't a bug per-se, it's just an unfortunate side effect of having raw pointers in a GC'd language.

You can avoid this by doing something like:

void *bytes = [someNSData bytes];
[self doSomethingWithSomeBytes:bytes];
[someNSData self]; //use someNSData again to keep it live

thundersteele
Apr 15, 2012, 04:13 PM
As others have suggested, i wouldn't worry about garbage collection and instead switch to using ARC.

adib
Apr 19, 2012, 08:18 AM
There is probably a reason why GC was short-lived. My personal experience was my app had persistent crashes on CoreGraphics when GC was turned on (http://cutecoder.org/software/news-anchor-mac-os-x-2-4-6-beta-3/).

As ARC is also a rather "new tech" that isn't much proven yet, I suggest using it only on new projects and don't convert your existing ones to ARC. Unless you're willing to spend a few days profiling and looking for leaks post-conversion.