Garbage Collection and Objective-C

There's no confirmation yet, but some encouraging rumors say that Leopard will include fully-supported garbage collection in the Objective-C runtime. The importance of this probably isn't obvious to novice programmers and non-programmers. Like a lot of programming terms, this is a simple concept which has an odd name. Garbage collection basically means "automatic memory management."

The significance is that garbage collection would remove one burden of writing Cocoa applications. Now, "burden" might be the wrong word. It's not even on the list of the most difficult things about software development. It's not an impossible task, just a matter of remembering to initialize and clean things up properly. The problem is that it's tedious work and minor mistakes can mean outright crashes.

Garbage collection means that Objective-C programmers would no longer have to balance their retain, init and copy invocations with release and autorelease. Not only does this mean software can be written faster, but it means that Cocoa applications would be a lot less likely to crash.

There's one other advantage, though, and this is one I'm particularly sensitized to. Once the issue of memory management is largely removed from the Cocoa equation, the barrier of entry for new programmers is dramatically lowered. The transition from scripting languages or Java isn't nearly as jarring, and smart people with good ideas will feel more comfortable diving right in and making an app.

Here's hoping this will be one of several major breakthroughs in Leopard.
Design Element
Garbage Collection and Objective-C
Posted May 5, 2006 — 28 comments below




 

John — May 05, 06 1168

Apple used to mention GC Obj-C right in its developer docs online, merely marked "not yet fully supported in Mac OS X 10.4" or somesuch. I wrote about it a while ago, but the links now lead to Apple web pages that don't mention GC at all. Anyway, you can google to find mentions of the existing Obj-C GC option(s?) in gcc.

Ylan — May 06, 06 1169

Dear Sir,

Listened to Blake Burris interview with Wil Shipley, on the former's great podcast CocoaRadio. Wil said something about that none of the applications that he was really fond of, were written in a GC-language. That it would be impossible to write Delicious Library in one for performance reasons!

With best regards, Ylan

Jesper — May 06, 06 1170

I consider this very, very confirmed on Apple's part.

From "man gcc":

-fobjc-gc
Enable garbage collection (GC) for Objective-C objects. The
resulting binary can only be used on Mac OS X 10.5 (Leopard) and
later systems, due to additional functionality needed in the (NeXT)
Objective-C runtime.

Additional functionality needed in the Objective-C runtime and can only be used in 10.5. How is this not confirming it? If you do believe that this does not confirm it, could you explain how Apple could *not* deliver this functionality in 10.5 and still save its bacon?

When functionality is announced in documentation in earlier versions, consider them a done deal.

Scott Stevenson — May 06, 06 1171 Scotty the Leopard

Additional functionality needed in the Objective-C runtime and can only be used in 10.5. How is this not confirming it?

It looks like it does, I just forgot about it.

lone — May 06, 06 1172

Also, in the very first version of the developer docs for Xcode 2/Tiger, I swear I have seen a -finalize method in the NSObject docs explicitely referring to "future versions" of the runtime employing garbage collection, that would call it rather than -dealloc. The current online version of the docs doesn't have it, though.

Jarl — May 06, 06 1173

I guess I prefer managing the memory myself, but if they have to, I hope there's an option to switch the damn thing off!

Aaron Tait — May 06, 06 1174

If there is a reduction of performance by using garbage collection, then I will simply not use it. From the looks of -fobjc-gc this means that I will just be a compiler option. While this would be great for people just getting into Cocoa programming, or any kind of object oriented programming for that matter; I don't think think that saving a few lines of code would be worth the performance trade off.

Michael Strck — May 06, 06 1175

"Wil said something about that none of the applications that he was really fond of, were written in a GC-language. That it would be impossible to write Delicious Library in one for performance reasons!"

So the same person who uses something as abstract and far-away from the hardware as Cocoa Bindings to keep insane amounts of on-screen information in sync (http://developer.apple.com/business/macmarket/deliciouslibrary.html) thinks it's beyond Apple to create a reasonably fast garbage collector?

Jesper — May 06, 06 1176

Michael: The same person who depends on the efficiency of an underlying layer doesn't want to add additional processing to it, correct.

GC will most certainly be optional. There's exactly 0 GC-enabled Obj-C apps out now. There's no reason to turn it on for all apps.

Scott Stevenson — May 06, 06 1177 Scotty the Leopard

I don't think think that saving a few lines of code would be worth the performance trade off

If that was the only benefit, I would agree. The point though, is really to simplify debugging for the developer and reduce crashes for the user. It's pointless to judge the performance impact until we have something to work with.

In any case, the higher-level abstractions always seem to win out in the long run. It happened with Quartz, Cocoa Bindings and even as far back as C versus assembly. So while you may not use it right away, you almost certainly will eventually.

Michael Strck — May 06, 06 1178

In any case, the higher-level abstractions always seem to win out in the long run. It happened with Quartz, Cocoa Bindings and even as far back as C versus assembly. So while you may not use it right away, you almost certainly will eventually.

I definitely agree. To stay with the above example, I find it highly improbable that a garbage-collected build of Delicious Libary would run any slower on the machines that will ship around 10.5's release than it does on today's high-end hardware.

Mike Zornek — May 06, 06 1180

I would welcome this tremendously. In particular it's very strange working with Core Data objects and that don't use reference counting in the same flow with regular Cocoa objects that do.

Jim — May 06, 06 1181

Mike - in what way does CoreData not follow the object ownership rules like the rest of Cocoa? In general it obeys the object ownership rules exactly. I'm aware of no exceptions.

Scott Stevenson — May 07, 06 1183 Scotty the Leopard

in what way does CoreData not follow the object ownership rules like the rest of Cocoa?

For the most part, the Managed Object Context does all of the memory management of Managed Objects and their ivars. You don't alloc/init them, you just fetch them.

Dan Price — May 07, 06 1187

What about the potential performance hit? Coming from a REALbasic and Java background, I'm very much aware that in any app of significant size, you can spend a great deal of time just working around the performance bottlenecks of reference-counting, not to mention related bugs in the framework that you have no power over. Then there's the problem of circular-references that prevent objects from being released. In my experience, it was an added problem not a benefit.

I like that in C++, there's a delete keyword. When you delete an object, it's gone. Compare this to REALbasic where you have to set every reference to nil and hope that the garbage collector gets the message.

Jim — May 07, 06 1190

Scott, sure you usually just fetch them. But they have a designated initializer, and they otherwise follow the ownership rules of retain/release. No special magic here.

Scott Stevenson — May 08, 06 1191 Scotty the Leopard

Scott, sure you usually just fetch them. But they have a designated initializer, and they otherwise follow the ownership rules of retain/release.

I guess I just don't quite agree. You really don't want to alloc/init managed objects yourself, or really even implement init. You're supposed to use awakeFromFetch, awakeFromInsert, and so on. You also typically don't retain managed objects. In addition, attribute and relationship values are memory-managed internally by things like setPrimitiveValue:forKey:.

So, yes, they are Objective-C objects, but the way you deal with data objects in a Core Data app are not the same as in a conventional app. That's the managed aspect.

jd — May 25, 06 1334

Quoting Steve Jobs:

"We are working on a better implementation for garbage collection than we've seen out there so far, but in the end its a performance hit and an unpredictable time that is not good for some kinds of apps."

Jim Lee — Jul 28, 06 1478

Other deep complex frameworks, like PowerPlant, have not suffered performance hits from garbage collection.

Ben — Aug 01, 06 1491

I'm all for this, with the option of turning it off. I hope some of the crusty old-school devs keep an open mind about it and don't try to shut it down before it can even get a foothold. With the speed of today's machines and the advances of tomorrow's, speed should not be as much of an issue as many fear. And Apple is not stupid, I'm sure they're thinking about many of the things that are being mentioned such as circular reference handling.

David — Oct 11, 06 2041

From a novice Objective-C/Cocoa programmer's point of view, automatic garbage collection can't come quickly enough! Though of course there ought to be a manual override to such a system (if elected to be used) on an individual variable basis, which would probably be the exact opposite to the 'autorelease' mechanism that's already in use.

Many 'average programmers' really don't want to be bothered with arcane memory management details; witness the rising popularity of languages such as Ruby, and the benefits of bringing more novice programmers on board will be reflected in an increase in the number of Mac OS applications. Indeed automatic garbage collection may even force more programmers to think in purely object oriented terms (with heavier use of accessor methods) as opposed to generally relying on the use of global variables.

Scott Stevenson — Oct 11, 06 2042 Scotty the Leopard

From a novice Objective-C/Cocoa programmer's point of view, automatic garbage collection can't come quickly enough!

True.

as opposed to generally relying on the use of global variables

I don't think many experienced Cocoa programmers are using a lot of global variables. At least I hope not.

private — Oct 20, 06 2112

Note that the quoted man gcc output is likely from a pre-release (10.5) version of the developer tools and the person submitting it is likely under NDA to NOT distribute/reveal that info.

The current (2.4) shipping public man information says the following:

-fobjc-gc
Enable garbage collection (GC) for Objective-C objects. The
resulting binary requires additional runtime support which is not
present in any released version of Mac OS X.

Scott Stevenson — Oct 20, 06 2114 Scotty the Leopard

Note that the quoted man gcc output is likely from a pre-release (10.5) version of the developer tools and the person submitting it is likely under NDA to NOT distribute/reveal that info.

As far as I remember, that man output slipped out into public. In any case, Apple's Xcode 3.0 page actually talks briefly about Objective-C 2.0 and garbage collection.

Mr B. — Dec 03, 06 2535

I don't really agree with the impact on performance of a GC scheme,
- OO is already slow compared with procedural
- Obj-C has an extra overhead to allow dynamic & late binding
- usually GC is a background process/thread with very low priority
- it's always possible to release the objects on the critical/bottleneck paths

I quite like Objective-C for the ease of distributing objects around without the "stubs & skeletons" mucking about and if Apple could address the issue of distributed garbage collection that would be ideal ... just hope they'll share with the GNUStep org.

Scott Stevenson — Dec 03, 06 2543 Scotty the Leopard

just hope they'll share with the GNUStep org

Their gcc changes are out in the open.

Techniq — Apr 14, 07 3906

I for one have now commited to learning ObjC after learning that GC would be available Leopard. Coming from Python background I was using the PyObjC bridge to write simple Cocoa apps. This was good but in some ways limiting and I ending having to learn ObjC syntax anyway to convert to the pythonic equivalent.

Research paper topics — Dec 29, 09 7044

Thanks for providing great guidelines!




 

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.





Copyright © Scott Stevenson 2004-2015