I agree. It seems like in the big scheme of things, automatic (or at least optionally automatic) memory management is a convenience whose time has come.

People who worry about the performance degradation this will have on the naive programmer's application seem to overlook the fact that new technologies with these caveats will always give veterans with perspective on performance an opportunity to easily outpace the competition. It's not like the world is going to become void of thoughtful programmers just because a new resource becomes available.

I find these the anti-garbage-collection arguments amusing - is there a more extreme premature optimization? Of course novice programmers will write novice code - eventually they'll learn enough fixing those problems not to be novices; in the meantime everyone else can spend less time on bondage-and-discipline programming and more on fixing the algorithmic issues which are almost always the root cause of poor performance.

Interrupt my process every n/th of a second and give CPU time to *someone else's process*?! No way that'll ever work for important software like MOD players or Lemmings.

I'm not sure I agree with Rosyna's assertion that Bindings "did almost everything for cocoa devs, cocoa devs thought it was great" or that it decreases "Cocoa's barrier to entry".

Bindings requires a good understanding of MVC and certainly doesn't do everything (as Scott notes). You can't just use it to whip up a release-ready app like a RealBasic or VB6 programmer could.

I think it's more of an impediment to newbie programmers starting out 'cause it increases the learning curve.

Core Data's the same.

It appears to me that Apple are actually increasing the quality of third-party apps and their platform by providing a solid foundation for development/developers.

However, Objective C garbage collection won't necessarily be the same. It won't require a learning curve. But it won't result in a flood a garbage apps as Rosyna fears. It will very likely only be available to 10.5 and this limits its application.

I think what is more relavent to me as a developer is how it will actually be implemented. I'm not too concerned about the performance (I'm sure Apple can do a decent job), it just seems to me that it could easily end up being only slightly easier to use garbage collection.

From a personal perspective, I have a pretty good grip on memory management now, and when I do I cock it up, it's generally due to an error in my design, rather than the lack of a garbage collector. I find that the memory management tends to correct me when I'm wrong!

People have always written crappy software. It's not just a case of things being so easy that any idiot can make something. Just look at Lotus Notes. One of the worst programs ever, but written mostly in C++ with antique APIs. Their poor choice of development environment shows up in the program. If they had taken the time they spent working on memory management and used it work on the interface, the world would be a better place.

The easier it is for a developer to focus on his good idea and not nagging implementation details, the better.

[em]The easier it is for a developer to focus on his good idea and not nagging implementation details, the better[/em]
Exactly. This is so important its not even funny. This is why cocoa does better than anything out there right now, even with semi-manual memory management. Now if it gets a garbage collector, all apple really is doing is changing the official memory management policy to something better. Coredata, Bindings, Key-Value Coding, NSView/NSEvent etc is just the standard apple-approved way to set up MVC in cocoa thats all.

I like it better now, then before where it was basically target-action and do-it-all-yourself and you had to decide how an app works in many fundamental ways... now its more like we have to worry only about how it logically architected. This is basically what webobjects devs have had since forever btw. And if you still wanna roll-you-own everything in cocoa or obj-c you can still do it.

Anyone know where to get basic GC info? Just curious!

Anyone know where to get basic GC info

Could you be more specific?

A specific garbage collector is described at www.ocaml-tutorial.org/garbage_collection - including some general points of consideration on the topic. A project that uses the conservative Boehm garbage collector for instance is nekovm.org.

Actually, GC can be faster then all that retain/release stuff.

For instance in Java, with EOF, you can fetch 10,000 objects into memory much more quickly, because you just have to move the top of heap pointer 10,000 times. Malloc has to allocate 10,000 separate blocks instead.

That said, the other reality is that GC is to some extent a trade off. Do you do a .1 millisecond call 10,000 times over the course of an hour, or freeze for 20 seconds to GC?

In java, what ends up happening sometimes is that you end up explicitly setting pointers to null after you're done with them, just so that the GC system knows you're done with the object asap. So you've traded retain/release/autorelease for "release".

Personally, I think the GC system will function great as a way to debug leaks...

because you just have to move the top of heap pointer 10,000 times. Malloc has to allocate 10,000 separate blocks instead

It's actually more complicated than that because all the object ivars have to be malloc'd as well.

On the other hand, you can sometimes avoid a lot of this overhead by doing a malloc of a large block of memory (sizeof(id) * 10000), and stuffing in the isa pointers in the appropriate places.

But yes, I understand the basic point you're making.

I have read that if you enable the garbage collection in Objective C, you can't mix and match with old non GC-ed code. Does this mean anyone who develops api addons for Objective C will need to develop two versions?

Does this mean anyone who develops api addons for Objective C will need to develop two versions?

I really have no idea but it seems unlikely.

I just decided to learn to program native OS X applications, and when I learned that Objective-C had no garbage collection I was disappointed and a little shocked. I've never had to manage memory in APIs I've used in the past, and I certainly wasn't looking forward to it. When I found out that garbage collection might be coming in OS X 10.5, I was excited about programming for Macs again. For me, G.C. is a goood thing.

Garbage collection in Mac OS X 10.5 can be faster than retain/release on multi-core systems. retain/release requires the code to obtain a lock, which is expensive. On multicore systems, libauto (the GC) can examine the heap before it pauses the thread so it knows what it's doing going in. And, if there are UI events in the queue, it'll abort it's job and wait for the next idle time. It's probably the most advanced GC on the market.

Does this mean anyone who develops api addons for Objective C will need to develop two versions?
No, if you actually examine the Objective-C runtime in Tiger (available from Apple's open source downloads), you'll notice that the runtime will ignore retain/release/autorelease calls. (Runtime support was added in Tiger, the collector makes its debut in Leopard.)

Not to disappoint you guys, I'm coming from the Java, C / C++ and Ruby world and can safely say that current incarnation of ObjC2.0 GC is nowhere near perfect and even good. It's a pity since I'm a 6-months old Mac convert who is blinded with the beauty and the elegance of Mac applications and API.

My poor impression of the GC is built on a practical experience rather than on theoretical speculations. A simple application with the table view in the main window shows it all. During the window resizing event handling, the internals of Cocoa allocate so many strings and integers that I run out of memory in less than 30 seconds. Memory profiler shows that the GC makes an effort to release memory blocks but irregularly and infrequently, which is obviously not enough to save the application from crash. If I perform window resizing in little steps releasing the mouse button all the time, the behavior is somewhat acceptable. Is it good? Not for me.

Personally, I find it a step back for myself to deal with memory allocation / deallocation in year 2008 after all these beautiful GC methodologies were discussed and implemented. Even Ruby, which is relatively new to the stage, has an almost perfect solution. Truth be told, RubyCocoa could be a great option should it provide a better integration with Cocoa internals (all these four-letter integer constants, third-party frameworks that you can't easily use etc). At least, Ruby GC is way superior.

The bottom line is: in early Nov'08 ObjC2.0 GC is still far from perfect. Very far.

@Aleksey Gureiev: A simple application with the table view in the main window shows it all. During the window resizing event handling, the internals of Cocoa allocate so many strings and integers that I run out of memory in less than 30 seconds

It's hard to say what's going on without looking at actual code, but it would be unusual to run out of memory so easily in the circumstances you describe. Xcode, for example, is an incredibly complex app with some unusual memory needs which runs under GC.

It's possible that some minor tweaks to your code could work wonders. It's not uncommon for new Mac programmers to run into discouraging but easily-fixed errors early on in their work. I've spoken to countless individuals who told me that Core Data or Cocoa was lacking in some way, only to discover that they had made some wildly incorrect assumptions about how the language and frameworks behave.

I'm not saying this is necessarily the case for you, but you'd be in the company of some very talented programmers if it was.

Since 2005 I have written several applications using Cocoa and Objective C. Last year I started to write a text editor using Cocoa, because in my job I had to deal with very specific programming languages for which there was no syntax highlighting. The editor features syntax highlighting, LatTex support, automatic substitutions etc. Having just moved to 10.5 at that time, I had the choice whether I wanted to adopt GC or use the old retain/release system. I decided to use GC for the new Cocoa project, although I knew that

a. the program would not run on older versions of Mac OS X
b. I might face some problems due to the GC framework still being buggy
c. I would lose direct control over memory management

As for a. and b., I think this is just a matter of time. Older versions of Mac OS X will simply disappear and the GC framework will be further enhanced.

As for c., I can understand that those who dislike GC fear that they lose control over the execution flow of their programs. It goes without saying that GC is not as efficient as allocating and freeing memory by hand. Still, for my part, I decided to hand memory management over to GC. Why? Because I believe that the goal of software development should be to write well designed and stable applications. Programmers spend a considerable amount of time trying to avoid memory leaks and dangling pointers. Even if you took great care while writing the code, you will find yourself skimming through the code from time to time checking all your release calls. Also, you will use debugging tools like ObjectAlloc to see whether you have overlooked something. This time is better spent improving the application's design and developing fast and stable algorithms. If an application performs poorly, this is more often than not due to slow algorithms. If the algorithm is bad, manual memory management won't make up for it. If you optimize your code according to Apple's Cocoa/Core Foundation guidelines as well as to general code optimization rules that help the compiler tweak your code, your application will perform well, even if GC is enabled.

Apple has done a great job enabling programmers to concentrate on the code that makes an application unique instead of having to do "monkey work". Interface Builder is a good example, as everyone knows who has ever worked with Java Swing or TKinter etc. GC is yet another way to boost programmers' productivity. This is what progress is all about. Remember the "law of diminishing returns" (cf. http://en.wikipedia.org/wiki/Diminishing_returns). For example, twice the effort/input does not necessarily yield results that are twice as good. If with effort 1 you reach up to 80%, you may only get 90% with effort 2, and only 95% with effort 3. If well written C code can be almost as good as hand-optimized assembly code, say up to 90%, why bother writing your programs in assembly language to squeeze out the last 10%? I think, this applies to GC vs. manual memory management as well.

I see no reason why new Cocoa apps should not be garbage collected, unless perhaps an application creates a myriad of objects and allocates loads of memory in a very short period of time. Yet, as far as I know, Apple's engineers are already working on a GC solution for these kinds of applications. Then again, sometimes allocating vast amounts of memory can also be a design fault.

While I still use manual memory management when I write small command line tools and the like, I prefer GC when working on bigger (Cocoa) projects, because it simply saves a lot of time and prevents my applications from crashing due to a silly oversight in the retain/release cycle. In the long run, GC is - for most applications - the way to go. In fact, I think GC in Objective-C was overdue.

Last but not least: Please note that if you want to develop Cocoa apps for the iPhone, you should stick to the old retain/release system as the iPhone does not (yet) feature GC.