Xcode Update Gives Objective-C Garbage Collection

William Henderson writes "That's right, if you haven't read it for yourself yet, Objective-C '2.0' now supports garbage collection. I foresee a great, huge, gigantic debate about to ensue, and a lot of java-heads sparking 'I told you so'. Why not start it here on slashdot?"

Comments

Here's my contribution to the debate.

[mccalli]

Fantastic.

I really do feel that manual memory management in most apps is now redundant. i fully accept its need in some cases an indeed I've advocated 'regressing' an app at work, which was ported from C to Java, back into C again to use manual memory management for performance. But that app's an exception - sub-millisecond performance is required. How many day to day apps need that?

I can feel myself waiting a few months, then ordering an updated Objective C coding book to pick this language up now.

Cheers,
Ian

In response to the naysayers...

[Hootenanny]

AFAIK, garbage collection may be enabled or disabled as a compiler option. If you don't like it, then just disable it and carry on.

Technical details needed!

[Anonymous Coward]

We developers will need far more technical details before we can even consider using this functionality in our applications.

What garbage collection technique is used here? How does it differ from the Boehm GC-based technique offered by the GCC Objective-C compiler?

Are any guarantees given with regards to the performance of the collector? Does it suffer from many of the problems that plagued the Java GC?

What sort of modifications do we have to make in order to take advantage of this support?

And Leopard has DTrace

[SuperKendall]

Far more exciting is that Leopard gets DTrace. Look at the last line of the page the story links to.

Well, let's say as exciting.

Not sure if you're joking, but...

[Space cowboy]

An autorelease pool is a promise that when the pool is released, any objects with a retain-count of 1 will be released. So, you create your objects and call the autorelease method on them:

          NSAutoreleasePool *pool = [NSAutoreleasePool new];
          NSObject *myObject = [[NSobject new] autorelease];

All that happens is that the object is added to an internal array, and when the pool itself is released, it calls [release] on all the objects in the array. I guess it actually calls [release] on the object as soon as it's gone into the array as well, or the object's retain count would be 2 when the pool was released (one for the 'new', one for the insert-into-array). So,

        [pool release] ... clears up after you, but it's no garbage collection, it's just a convenient way of using retain/release.

ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.

Simon

Re:uh, neat....

[jfengel]

It isn't even a question of how good a programmer you are. It's a question of how good a programmer everybody on the team is. And "team" includes every library you use.

When memory is passed across the boundary from one developer to another, you need some kind of mechanism to track who is going to free that memory, and under what circumstances.

Garbage-collected languages make that contract fairly clear. (But not infinitely clear; there are still ways to accidentally pin objects in memory even in a GC language).

In C we got used to putting in comments saying, "I'm passing you back a static structure, so I'm not re-entrant" or "This thing is malloc'ed so free it when you're done" or "You have to pass in a reference to that object and I'll fill it in". As long as discipline is followed the program works brilliantly (no GC overhead) but if any developer anywhere on the project misreads any single one of those comments, you're completely and totally doomed.

There is still software to be cranked out by one guy who can keep the entire thing in his head, but software requirements for most things are too big for just one guy. Even the uberest of uber-hackers is limited by the dumbest guy on his team, especialyl when that dumbest guy (even if he's pretty damn smart) nulls out a memory location that wasn't finished yet.

Re:Hacks and Novices Rejoice!

[profet]

"Garbage Collection is cool cuz you don't have to, like, remember to delete stuff"

Shudder.

posted wirelessly via abacus and smoke signals

Your knowledge of GC is 10 years out of date

[jbellis]

Modern GC is *faster* than hand-coded free calls in 90% of situations.

"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion." -- http://en.wikipedia.org/wiki/Garbage_collection_(c omputer_science)

--
Carnage Blender : Meet interesting people. Kill them.

Re:Your knowledge of GC is 10 years out of date

[CoughDropAddict]

Modern GC is *faster* than hand-coded free calls in 90% of situations.

Greater throughput at the expense of latency. GC stops the world.

"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion."

I would like to offer you a bank account with 50% interest amortized over 500 years. I regret that you will not receive your first interest payment until the 500 years are up.

The point is that amortized performance gives you no control over when you're going to take the hit. That's OK if you only care about throughput.

NOOOOOOO #@$#$@

[pestilence669]

Objective C has one of the most elegant reference counting implementations on the planet. Virtually no thinking at all is required to manage memory. Cyclical relationships, which shouldn't exist in decent code, are its only limitation. It's also very fast. Anyone who argues that memory management in Objective C is difficult, should have their head examined.

Garbage collection is a step backward, IMO, but every language seems to be moving in this direction. I really do believe that resource awareness is crucial to efficient programming. Garbage collection encourages lazy programming habits, which I've seen in quite a few Java developers. Bad habits, once bred, are hard to get rid of.

Now, instead of profiling memory for leaks, you can profile the garbage collector, which I predict will be just as much of a headache as tracking down a memory leak. In the end, little work is saved, at least from my experience debugging other developers' Java applications. I won't know for sure until I play with XCode 3.

Re:NOOOOOOO #@$#$@

[pikine]

Objective C has one of the most elegant reference counting implementations on the planet.

There is no need to panic. You can support both reference counting and garbage collection in one run-time, provided the objects are in separate heaps. Whenever there is a reference from reference counting heap to the garbage collected heap, you simply tell the GC that there is a "root" reference inside a reference counting object. The other direction is probably even easier. A conservative GC can discern whether a reference is managed by the GC or not. Otherwise, we can foil a GC's attempt at traversing outside of the GC heap by marking a reference as an integer or by wrapping it in a special binary object that GC does not traverse.

Now, instead of profiling memory for leaks, you can profile the garbage collector, which I predict will be just as much of a headache as tracking down a memory leak.

Ever heard of suggestions that global variables are harmful? This is even truer for GC memory management. These globals have roots that persist throughout the lifetime of a program. For this reason, Java programmers seem to suffer more GC problems than a functional language programmer. In fact, the only place you need to look at, in the case of a "GC memory leak," is your global variables.

Unless a GC implementation is flawed, GC does not produce memory leaks. The leaks you are talking about are still technically used by the program but the programmer is not aware of it.

Debugging reference counting is just as much work as debugging malloc/free. In both cases, you need a map tracking the creation, duplication, and consumption of references.

Garbage collection is a step backward, IMO, but every language seems to be moving in this direction. I really do believe that resource awareness is crucial to efficient programming.

If by efficient programming you also take into account run-time overhead, some implementation of GC is more efficient than some implementation of malloc/free. For example, a copying GC only maintains a "heap top" pointer, and any new object is allocated from heap top only. In contrast to malloc/free implemented as linked list traversal, GC takes O(1) time to allocate, and O(n) time when it runs out of memory; malloc/free always takes O(n) time.

I'm sure other people will fill in the details here if they want to. The point here is that you cannot compare blanket GC with blanket reference counting or malloc/free.

If by efficient programming you mean the time it takes to write code, I believe GC is the winner here, since you forget you're using memory altogether.

Re:NOOOOOOO #@$#$@

[m874t232]

You're missing the point of garbage collection. Garbage collection isn't there to save your effort. In fact, garbage collection does not save you effort at all. The purpose of garbage collection is to make the language safe and isolate errors, something that no other storage management scheme can achieve.

Both manual storage management and garbage collection each require a lot of experience to use correctly. Your problem is likely that you underestimate both how much work it took to become proficient at manual storage management/reference counting, and how much work it would take you to become proficient in a garbage collected environment.

Re:NOOOOOOO #@$#$@

[bar-agent]

Objective C has one of the most elegant reference counting implementations on the planet. Virtually no thinking at all is required to manage memory.

Oh, is that why the Cocoa-Dev mailing list has a brand-new reference counting question every damn day? It is clearly not as simple as you think.

Re:NOOOOOOO #@$#$@

[grammar fascist]

Garbage collection is a step backward, IMO, but every language seems to be moving in this direction. I really do believe that resource awareness is crucial to efficient programming. Garbage collection encourages lazy programming habits, which I've seen in quite a few Java developers. Bad habits, once bred, are hard to get rid of.

You're missing the point, which is to make it easier to model a language mathematically. The easier the model is to reason with, the fewer errors you'll have. It frees your mind from petty concerns that arise from having an overly-complex language model.

We'll go back to Lisp to elucidate this, which has always cleaned up after itself. Lisp has a very strict underlying mathematical model. Consider math for a moment. Once you define something, is it ever undefined? If you've stated a truth, is it ever not true?

No. Likewise, in languages with garbage collection, once you create something, it exists, theoretically, forever. In the theoretical language model, memory is infinite. The fact that something cleans up stuff that isn't referenced because we happen to be using state machines rather than true Turing machines and need the memory back is merely a necessity of living in the real world.

There's a beauty and an elegance about "garbage collection" (i.e. the more-mathematical infinite memory model) that you're totally missing out on.

Mathematically speaking, mutable variables are a bad habit. As you say, bad habits, once bred, are hard to get rid of. Can you break this one? You don't have to, just think about it. The point is, I'm challenging you to expand your mind a bit and understand that what you hold dear isn't all there is in the world of programming.

Cyclical relationships, which shouldn't exist in decent code...

Where did this piece of utter tripe come from? Haven't you ever created a circularly-linked list? Must everything in memory be a tree?

Re:Yay! More Bloated Crappy Code

[Maury Markowitz]

Practically every program I run under XP has a memory leak. As a result, quitting out of any of then leads to 15-20 seconds (yes, really) of disk griding while the VM dies. And this is on *quitting*. Does anyone else find it the least ironic that it takes longer to quit a program than start it?

I love listening to people complain about GC. Of course *they* are super-programmers that don't need any of this stuff, because their code never has *any* problems in it. But here I am with all these leaky programs. They leak memory all over the place and don't care. Why? Because I don't *need* to care about memory, everyone has 1GB anyway.

Oh dear, where to start ?

[Space cowboy]

• Because it can be a lot slower than C++.
  Well, actually if you really *need* speed, then ObjC groks C perfectly - it's a cast-iron guarantee that any legal C will work in objC, unlike C++. C performance is just as good as C++...
  
  
• C++ gives you control over the object messasing system whereas Objective-C uses virtual methods for pretty much everything and there is nothing you can do about it.
  Um, no. Objective C uses dynamic despatch (ie: the method to run is determined at runtime not compile-time. This is one of its most powerful features. As for "nothing you can do", you can retrieve the bound method as an IMP (like a function pointer) and call it directly to remove any overhead. Useful in loops.
  
  
• Objective-C is actually a lot like COM which is Microsoft's object extension for C. It was designed about the same time with many of the same goals. Both basically came about because of the incredibly slow progress C++ was making at the time.
  No. Objective C was designed as an adaption of the ideas behind smalltalk, as applied to C. It was designed in the early 1980's, COM was designed in 1993, although it wasn't called COM until 1997.
  
  
• Objective-C has no template system. This is a huge advantage for C++.
  Well, that's a matter of opinion, but in any case, Objective C is a dynamic language. Most of the power of templates is encapsulated within the dynamic-despatch abilities of the language, coupled with the 'protocol' feature of the language.
  
  It could be said that Objective-C is a lot like Java with many of the same problems but because it was never marketed with a cross-platform VM it didn't take off like Java.
  I think it is significantly like java, but it's compiled (like C/C++). It's a *lot* faster than Java, and handily beats gcj too, at least on the tests I've done. You need to enumerate these "same problems" before I can respond though.
  
  
• Overall C++ is more C-like than Objective-C. That is it gives you much more control over the exact level of performance versus ease-of-use that you want
  Um, take any legal C code and it *might* compile in C++. It *will* compile in ObjC - how can C++ be "more like C" than ObjC ?
  

ObjC has introspection, dynamic binding, (now) optional garbage collection, (always) a very easy retain-count allocation system, really easy-to-learn constructs (I think there's 12 new statements, or something like that), *and* a weird syntax - it grows on you though :-) It actually does surprise me that more people don't like it. If Macs get more popular, who knows, perhaps it will have its day in the sun...

You need to read the PDF manual. There's a lot of stuff you're saying as fact, that is simply wrong.

Simon

Re:Why not Objective C?

[Novajo]

Objective-C has no template system. This is a huge advantage for C++.

This is interesting because C++ has templates only because it needs them and Objective-C doesn't have them because there is no need. For instance, you can't have a C++ array of "anything", unless all objects descend from the same class, and then you are restricted to functions that were declared in that base class. That's because C++ is statically typed and needs to know the virtual table to use for the function call (whatever the function is). On the other hand, Objective-C does not need templates because function calls are not looked up through a virtual table, they are dynamically sent as messages, which are handled if the object implements that function. Hence, you can (and do) have a general-purpose array in Objective-C. You can even have a general purpose hash table with changing element types...! I'd love to see an implementation in C++ that is readable.

The "Object Penalty" (i.e. the cost of using a certain object-oriented language) is fixed, and it therefore reduces over time with faster and faster computers. C++ will do anything to make that cost as small as possible, including getting in your way. So really, the advantages of C++ are decreasing over time if you consider all the hoops you have to jump through to get what you want. When you really need performance in Objective-C, you write that little snippet of code in straight C (just like everyone else does in C++ .)

I was a C++ junkie for 10 years until I tried Objective-C and quickly noticed how much more complex a task I could handle without the language getting in my way. You should try it.

ObjC Referencing Counting In A Nutshell

[Anonymous Coward]

The entire scheme is lexical. If you do a [obj retain] you are responsible for doing the [obj release]. So,

[[NSMutableArray alloc] init]

will require you to release the array object, but

[NSMutableArray array]

won't. Objects added to autorelease pools are automatically released at the end of each runloop. It's a convenience thing... so instead of doing:

NSMutableArray *ary = [[NSMutableArray alloc] init];
[someObject setValue:ary forKey:@"someKey"];
[ary release];

you can do either [[[NSMutableArray alloc] init] autorelease] or [NSMutableArray array] (which does exactly the same thing) and drop the release. Voila! One whole line of code saved/invested. Also you can use ObjectAlloc (from a menu in Xcode) to see stacks of everything that has been allocated.

Having said all of that, memory management is tricky in Cocoa because *everything* is tricky in Cocoa. Lots of entry/exit points in the code which can make it difficult to determine where a problem occurs even w/ NSZombie's and a nice stack trace. Complicated user paradigms, i.e. cut & paste and undo & redo.

That's not a complaint, just a statement. More options = better.