waffle

Waffle is a weblog.
The author of Waffle, some guy in Sweden, also occasionally writes stmts.net.

Purer Garbage

As long time readers (and by long time I mean “more than a week”) will know, garbage collection has recently been on my mind – namely the proof that Apple will include Objective-C garbage collection in Mac OS X 10.5 codenamed “Leopard”, and set to be unveiled at this year’s Worldwide Developer Conference in August.

Or is it?

Xcode 2.3 just came out, and with it a newer revision of Apple’s version of GCC 4.0.1 (the original revision of 4.0.1 was included in Xcode 2.2). Most intriguingly, the man gcc output has changed when it comes to the infamous -fobjc-gc option! Here’s the new text:

       -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.

       When the -fobjc-gc switch is specified, the compiler will replace
       assignments to instance variables (ivars) and to certain kinds of
       pointers to Objective-C object instances with calls to interceptor
       functions provided by the runtime garbage collector.  Two type
       qualifiers, "__strong" and "__weak", also become available.  The
       "__strong" qualifier may be used to indicate that assignments to
       variables of this type should generate a GC interceptor call, e.g.:

                 __strong void *p;  // assignments to 'p' will have interceptor calls
                 int *q;            // assignments to 'q' ordinarly will not
                   ...
                 (__strong int *)q = 0;   // this assignment will call an interceptor

       Conversely, the "__weak" type qualifier may be used to suppress
       interceptor call generation:

                 __weak id q;      // assignments to 'q' will not have interceptor calls
                 id p;             // assignments to 'p' will have interceptor calls
                   ...
                 (__weak id)p = 0;   // suppress interceptor call for this assignment

Still there? Good.

First of all, this version doesn’t mention OS X 10.5 in the least, whereas the previous version did very blatantly. What this means is that the feature is no longer guaranteed to be in for 10.5. My guess is that it will be in, but due to the change of operation (which I’ll come to in a second), Apple didn’t want to signal it too strongly.

Second, this method is definitely different than what we had before.

The Xcode 2.2 GCC (which is what I’m calling it, since both Xcode 2.3 and 2.2 GCC have the same version number – 4.0.1) had something else in mind entirely. It spoke only of a weak reference type (and not a strong reference type), and the Foundation Kit documentation in Xcode itself also noted the infamous finalize instance method on NSObject (the root object in Apple’s frameworks) which was designed especially to give you a dealloc-like hook for closing file handles and performing major cleanup. Xcode 2.3 GCC speaks of strong references as well, and the new Foundation Kit documentation in Xcode never mentions the finalize instance method at all.

Are we in for a brand new garbage collector before we even saw the first?

(Postscript: leeg notes in the comments that it could be a new way of describing the “old” GC with some amendments, which is true, and which is why I ended the post with a question. I truly don’t know a whole lot about the insides of garbage collectors, and I’m hoping for more input.)

Comments

  1. Note that Foundation and Cocoa both already implement the finalize method on what looks like all their classes. I hope very much that it’ll be in; GC would be cool.

    By Johannes Fortmann · 2006.05.25 22:42

  2. I think this could just be a different way of looking at the same collector, really. -finalize could just have been removed due to some “oops, shouldn’t have mentioned that” moment. Similarly, the __strong (why not @strong and @weak? are we saying this is a framework GC, and not an inherent ObjC GC? If so, why does it need runtime support?) keyword may merely have come about because someone observed a need for it, which previously hadn’t been considered to exist. You might think “always GC, except when you ask not to” then realise that there are cases when the GC doesn’t mark a reference and you’d prefer if it did.

    I’d like to be told at this year’s WWDC that NSObject now contains these methods: -(id)retain { return self; } -(oneway void)release { return; } and that everyone can either throw their release pools away or not, it doesn’t matter. That would be the way to get devs on board with GC…..

    By leeg · 2006.05.25 23:12

  3. it seem like everyone thinks GC is a missing feature in Obj-C, but thats what I loved the most in the language when I first started coding on OS X. the retain/release or the autoreleasepools are in my opinion, a firm reminder that memory management is still a part of your job as a developer in order to have a great app. Just as an example of C# and GC on windows, I had to order a rewrite because no one was actually using this “tiny” app, with claims that “how can a simple app eat more resources than word or excel?”.

    By Emidio · 2006.05.26 09:40

  4. In my opinion, GC is just the next step on the ladder towards optimizing programming for the programmer, not for the processor. Writing everything in Assembler gives you total absolute control and the potential for a very optimized program. Do people want these things? No – they want to get their job done, faster, better and hopefully yesterday as well. In essence, the more you can abstract away the better except for extreme cases like drivers and the frameworks themselves.

    Not having a GC requires that everyone be great at memory management. I could see people arguing that people who are not great at memory management are not fit to program, and I could see other people arguing 25 years ago that people who are not great at LISP, COBOL or Assembler are not fit to program. The people that have been arguing this have consistently come through as either wrong or elitist pricks, and not uncommonly both.

    You could memorize the camel book completely and still be clueless as how to write a practical Perl program. No, the secret to programming is entirely about getting the think of it and being able to learn new concepts, not in knowing everything. Here, the GC fills an important part of abstracting away something that’s tedious. That some of today’s GCs are horribly inefficient isn’t awesome, but it’s to be expected. Even if GCs never progress beyond their current point (which is a big concession and a ridiculous assumption, but nevertheless what some people base their arguments on), the constant progression of technology will eventually make sure it’s a solved problem. That it’s not as optimized as it could be matters little to those who can produce more than they could before.

    By Jesper · 2006.05.26 12:27

  5. Strictly speaking, retain/release is already a form of GC, as you only know under which condition the memory is released (when the reference count falls to 0), but not which release call is going to do it. But as GC algorithms go, manual reference counting is one of the more brittle and unreliable ones.

    And if a programmer is incapable of keeping the memory behavior of his application in mind, he’ll write bad apps regardless of having a GC or not.

    By Lars · 2006.05.27 06:12

  6. My counterpoint is exactly that: reference counting is brittle and unreliable. You frequently have to use other people’s code via libraries, and it’s often guesswork. You don’t have to be a bad programmer to make missteps with refcounts, you just have to use a library written by someone who’s not 100% perfect. And chances are that if a new version comes out, and that version fixes it, and you didn’t notice, the app may leak or crash seemingly out of nowhere.

    I don’t think this was clear in my last comment, but I do agree that you should know how memory management works at basic levels – suddenly allocating 30 billion objects and expecting o(1) performance throughout the operation is boneheaded. But I also think that memory management causes more headaches when it’s manual than when it’s automated, regardless of if the automation makes it run a bit slower and take up a bit more memory.

    (Emidio’s point was that C# apps take up more memory because they use GC, which is false. They take up more memory because they use JITC and a big framework. The GC doesn’t exactly help boost performance and slim the memory footprint, but placing all the blame there is from what I can tell wrong.)

    By Jesper · 2006.05.27 13:37

  7. My bad, I agree that my comment was misleading, GC is not to blame for the whole bad experience in this particular app, but I do think that when it comes to memory management, it does discourage the developer from even thinking about it – and sometimes, from even knowing how it really works – and that’s the issue that I was trying to point.

    By Emidio · 2006.05.30 14:47

Sorry, the comment form is closed at this time.