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.
Garbage Collection and Objective-C
Posted May 5, 2006 — 28 comments below
Posted May 5, 2006 — 28 comments below
John — May 05, 06 1168
Ylan — May 06, 06 1169
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
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
It looks like it does, I just forgot about it.
lone — May 06, 06 1172
Jarl — May 06, 06 1173
Aaron Tait — May 06, 06 1174
Michael Strck — May 06, 06 1175
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
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
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
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
Jim — May 06, 06 1181
Scott Stevenson — May 07, 06 1183
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
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 Stevenson — May 08, 06 1191
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
"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
Ben — Aug 01, 06 1491
David — Oct 11, 06 2041
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
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
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
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
- 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
Their gcc changes are out in the open.
Techniq — Apr 14, 07 3906
Research paper topics — Dec 29, 09 7044