Tag Archives: garbage collection

Objective-C and the Web

Earlier today, courtesy of @GlennChiuDev, I was reading Kevin Lawler’s informal tech note about using Objective-C to power the Web. I found myself agreeing with quite a lot of it.

I then had the chance to read @heathbordersresponse to the original post, which I realized I was also agreeing with in considerable measure.

So here’s my response to both. I’ve assumed that readers have at least skimmed both the original post and the response so that I don’t have to do what Heath did and duplicate everything they said here :).

Kevin makes the point that Apple has hugely improved Objective-C in recent times, especially with the most recent releases of OS X and iOS. Heath objects that while Objective-C has certainly improved, it’s still a strict superset of C and comes with all of C’s well-known and discussed-to-death problems.
While I agree with every one of Heath’s list of issues with Objective-C, my thought is that everyone works best in whatever works best for them. Some people (myself included) are going to be more comfortable in a bare-metal-with-extensions language like Objective-C, while others are never going to enjoy it in comparison to Java. It’s a personal thing, and I’d argue that a programmer who doesn’t like Java, for whatever reason, will never save time in it no matter how many conveniences it provides over Objective-C. Heck, I get plenty of scripting done in PHP even though I agree that Python and even Ruby have enormous language advantages and that PHP has severe community and design issues, because I’m extremely familiar with it.

Kevin goes on to say that Java was meant to be a write-once run-anywhere language but failed at it, and Heath counters by pointing out that Java does indeed do this.
This isn’t really a simple argument in either direction. Java was indeed intended as write-once run-anywhere, but while Java CLIs and servers do fulfill this promise for the most part, I think Kevin was thinking (as I did at first) of Java GUIs. To a one, I have never met a Java GUI I like, on any platform. Java apps look and act horribly non-native on OS X, are slow (and odd-looking, if less so) on Windows, are just as clunky as everything else on X11 (my personal opinion of all the X windowing toolkits is that they all stink), and as for Android… well, I don’t like Droid, and even that aside, Java working “right” on one platform is the exact opposite of the promise. In that respect it might as well not be any different from Objective-C in its platform dependence.

I do have to agree with Heath and disagree with Kevin regarding writing portable C/C++ being easy. Even if you use only POSIX APIs exclusively, which will severely limit your functionality in the general case, this is a nightmarish undertaking. Even if you restrict yourself only to Linux variants, nevermind trying to work with all the other UNIXen, OS X, and Windows, it’s all but impossible without a complex system like autoconf (which is another entire rant about horrible garbage in the making).

With regards to the JVM, I have to agree with Heath again: The JVM is absolutely a useful UNIX system layer, and JIT does make it a lot less slow than Java used to be. Similarly with garbage collection; GC is an abomination in C and Objective-C, but that’s because the design of those languages precludes the collector having full knowledge of what is and isn’t a live object without very restrictive constraints. In a fully virtualized language like Java or C#, properly implemented garbage collection is absolutely a useful technology.

I can’t say much about Java re: Oracle, since I don’t know much of what really happened there, but just from reading the respective posts, I have to say Heath makes a more persuasive argument than Kevin’s declarative statements.

Kevin then goes on to say that object-oriented programming is a win over functional programming, and Heath objects, saying that there are a great many people who disagree. In this case, while I personally agree with Kevin in my own work, this is another area where personal preference and training will trump blanket statements every time.

Kevin also talks quite a bit about Automatic Reference Counting (ARC); Heath didn’t respond to this section. I find ARC an absolute divine gift in Objective-C, but all ARC does is bring the syntax of GC to a non-GC environment, and in an incomplete fashion: The developer must still be careful to avoid retain cycles with weak references and explicit nil-ing of strong references.

Kevin goes on to talk about Apple’s failed WebObjects project. He gives some reasons and thoughts about Apple moving Objective-C to cross-platform deployment. He seems to be unaware of GNUStep, ObjFW, and other similar projects, but setting that aside, I absolutely agree that Apple bringing the full Objective-C runtime, including most if not all of Foundation, to a wider UNIX base would be spectacular. Reviving and expanding the former OpenDarwin project would also be awesome, in my opinion. In this, I’m completely on Kevin’s side; this should happen and he lists several good reasons for Apple to do it.

Now Kevin goes on to say what is no doubt the most controversial thing in his entire post: “Xcode is an excellent IDE, with tolerably good git support.”

Like Heath, I must say: This. Is. Patently. False.

Xcode 3 was a tolerably good IDE, absolutely. Not modern or fully-featured by any measure, but fairly decent. Xcode 4, however, is a crock of <censored>. I’ll let Heath’s response speak for me on this for the most part, but I’d like to add that Xcode’s git support is also absolutely abysmal. Worst of all, there’s no way to shut it off, even if you never told Xcode that the project had a git repo.

So to summarize, what Kevin seems to have posted is a rant about his issues with functional languages and Java, and his love for Objective-C, without a lot of facts to back it up. I’m strongly in agreement with his feelings on most points, and I totally agree that Objective-C would be an awesome language for Web programming, but I suspect Apple hasn’t gotten into the field exactly because Java isn’t the terrible beast he made it out to be. This is a shame, to be sure.

As a footnote to those who still follow this blog hoping for a post on this subject: Missions of the Reliant isn’t dead! I’ve been pretty busy for a long time, but I will find time to work on it!

A handy trick with blocks and callbacks in Objective-C

While writing some code to implement a block-based callback on top of some classes which are still stuck in the target-action paradigm, I stumbled across this rather nice little trick for doing so in a category without having to do any memory management tricks at all in retain-release mode. This example comes from adding a block callback to iOS’s UIBarButtonItem (DR is for Dark Rainfall, of course):

// This category is required, but doesn't have to be in the same place.
// The concept is simple, and used by several other code libraries: Because blocks are
// also objects when the Objective-C runtime is loaded, a category on NSObject adds
// the selector to them. Obviously it would be foolish to call this category on an object
// that was not a block.
@interface NSObject (DRBlockCallback)
- (void)DRcallbackBlock;
- (void)DRcallbackBlockWithSender:(id)sender;
@end

@implementation NSObject (DRBlockCallback)
- (void)DRcallbackBlock { ((void (^)())self)(); }
- (void)DRcallbackBlockWithSender:(id)sender { ((void (^)(id))self)(sender); }
@end
// Now for adding a block callback...
@interface UIBarButtonItem (DRButtonBlockCallback)
- (id)initWithBarButtonSystemItem:(UIBarButtonSystemItem)item block:(void (^)(id))b;
@end

@implementation UIBarButtonItem (DRButtonBlockCallback)
- (id)initWithBarButtonSystemItem:(UIBarButtonSystemItem)item block:(void (^)(id))b
{
    // Call correct initializer. Provide the block callback as action, but no target yet
    if ((self = [self initWithBarButtonSystemItem:item target:nil action:@selector(DRcallbackBlockWithSender:)]))
    {
        // It's necessary to copy the block and hang on to it somewhere. Categories can not add
        // ivars to a class. Associated references were designed to solve exactly this kind of
        // problem. This call associates the block with this object, conveniently doing the needed
        // copy as well.
        objc_setAssociatedObject(self, "DRactionBlock", b, OBJC_ASSOCIATION_COPY_NONATOMIC);
        // Now when the block is retrieved back from the association, the copy is returned, which is
        // the target for the block callback action.
        self.target = objc_getAssociatedObject(self, "DRactionBlock");
    }
    return self;
}

// There is no need to override dealloc. The association will automatically be dissolved when the
// object is released, at which point the copied block will also be released.
@end

Poof. Proper management of a block’s memory in a retain-release environment without any effort! This little trick could be further simplified by another method on NSObject, something like - (id)associateBlock:(void (^)(id))b withKey:(const char *)key;, but that’s overkill in my opinion. For completeness’ sake, I also wrapped the whole thing in #if NS_BLOCKS_AVAILABLE, though on iOS that’s probably unnecessary, as I have no intention of ever developing for <4.0 again, and even on OS X I would use PLBlocks if I had to target Leopard.

For those waiting for Missions of the Reliant news, I beg your patience. I have not forgotten!

Missions of the Reliant: They’re locking phasers.

“Lock phasers on target.” – Khan
“Locking phasers on target.” – Joachim
“They’re locking phasers.” – Spock
“Raise shields!” – Kirk
“FIRE!” – Khan

The Reliant now has targetting and scanning systems implemented. There’s still several bugs to work out, but the basic system is in place. When that one little fighter I put in as a test shows up, the ship can lock onto it. Of course there’s no indication on the radar (since there isn’t a radar yet) and no way to destroy it (since there isn’t a laser cannon – though there are laser couplings – or torpedo holds or torpedo launchers yet), but at least we can scan it! Or we could if fighters weren’t always unscannable. Oh well.

Still, that little flashing box on top of the fighter is darn aggressive.

The reason I don’t have more to show than a buggy targeting system is I spent the majority of the time implementing it also working out a huge mess of memory management bugs I’d been ignoring since day one. Leaks, retain cycles, overreleases, you name it. What kills me is that the Leaks tool missed all but a very few of them. I ended up with manual debugging of retain counts by calls to backtrace_symbols_fd(). As uuuuuuuuuuuuuuuuuugly as lions (Whoopi Goldberg, eat your heart out). In the end a few tweaks to the way things were done were in order. Too much work being done in -dealloc when I had a perfectly good -teardown method handy that functions much like the -invalidate suggested by the GC manual.

Why aren’t I using GC and saving myself this kinda trouble? Frankly, given my current understanding of things, I think GC would be even more trouble than this! This, at least, I understand quite thoroughly, and I have considerable experience dealing with the issues that arise. I know how to manage weak references properly to avoid retain cycles and how to do a proper finalize-vs-release model. I haven’t even gotten tripped up by hidden retains in blocks more than once! Yes, I screwed it up badly here, but that’s because I was paying very little attention. I do know how to do it right if I try, and now I’m trying.

Garbage collection, on the other hand, is a largely unknown beast to me, and from what I’ve read on Apple’s mailing lists, the docs Apple provides are very little help to developers new to the tech. The hidden gotchas are nasty devils, much worse than hidden retains in blocks. Interior pointers and missed root objects come to mind, especially since I’m targeting 10.5 where GC support was still new and several bugs in it were known to exist (and may still). Apple chose to provide an automatic stack-and-heap scanning collector, whereas I would only have been comfortable with a manual heap-scanning collector, which is really little more than autorelease anyway. In such a light, the model I’m familiar with and clearly understand seemed a much better choice than trying to learn an entirely new paradigm for this project. Ironically, I still chafe at manual memory management in C++ projects, especially the lack of autorelease, and as with GC, I don’t understand such things as auto_ptr and shared_ptr well enough to get any use of them. Templates make me cringe.

With the targeting scanner implemented, all I need to do is debug it. The next step will be to write the radar, so as to double-check that the fighter AI is working as it should and that the target scanner is de-targeting properly when something falls out of range. After that I need to test the scanner versus multiple targets, especially the new smart-targeting mode I’ve added as an easter egg. What can I say, it always drove me nuts that it targeted “the next enemy in the internal array of enemies” rather than “the nearest enemy to my ship”. But finding how to enable it is left as an exercise to you nostalgic people like me who’ll actually play this port :-).

Come on, iTunes. Jesse Hold On – B*Witched? *punches the shuffle button* 太陽と月 – 合田彩. Much better! Sorry, interlude *sweat*.

Anyway, once the scanner can handle multiple targets, it’s time to implement the third and final component of the laser: the cannon. Time to blow things up with multicolored hypotenuses of triangles! I might even study up on a little QTKit so I can take movies from the OpenGL context to show off. Bandwidth, though; this blog isn’t exactly hosted off DreamHost. (Linode actually, and they’re really awesome). Oh well, we’ll see. Maybe I’ll even leave the feature in as another easter egg…

To summarize, the current plan is:

  1. Fix bugs in target scanner.
  2. Implement radar.
  3. Spawn multiple targets for the target scanner.
  4. Implement laser cannon.
  5. Maybe implement movie capture of gameplay.
  6. ???
  7. Profit!

I’m not making it up as I go, I swear!

Subtle pitfalls of doing things in -dealloc

Let me describe the setup for this issue.

Take a gobal (set property on a singleton object) list of objects which holds only weak references (in this case, if it held strong references, the objects would never lose their last retain and could never be deallocated, yes I know GC avoids it):

@implementation Singleton
- (void)init
{
    if ((self = [super init]))
    {
        CFSetCallBacks cb = { 0, NULL, NULL, CFCopyDescription, CFEqual, CFHash };
        NSMutableSet *container = (NSMutableSet *)CFSetCreateMutable(kCFAllocatorDefault, 0, &cb);
    }
    return self;
}

- (NSMutableSet *)container { return container; }
- (void)setContainer:(NSSet *)value { if (value != container) { [container setSet:value]; } }
// The other KVC-complaint methods for an unordered to-many relationship

// Singleton pattern stuff here
@end

Now consider a class which, as part of its initialization and deallocation, adds itself to and removes itself from this singleton’s container:

@implementation ListedObject
- (id)init
{
    if ((self = [super init]))
    {
        [[Singleton singleton] addContainerObject:self];
    }
    return this;
}

- (void)dealloc
{
    [[Singleton singleton] removeContainerObject:self];
    [super dealloc];
}
@end

This pattern is useful when you need to track every instance of a given class – in this case, my actual code maintains the set property as a property on the class object itself rather than a separate singleton, but the result is the same and I thought I’d use something more familiar for this example.

The first time you release an instance of ListedObject to the point of deallocation, you’ll crash during your next event loop.

Next event loop? Experienced Cocoa readers will immediately guess “autorelease pool”. And they’d be right. To debug this, I added backtrace_symbols_fd() calls to -retain and -release of the ListedObject class. This may seem strange versus using a GUI tool like Instruments’ “Object Allocation” template, but I’m old-fashioned and this was simple. The object was indeed being overreleased, with the extra release coming from the main event loop’s autorelease pool.

The cause is rather intricate. At the time of the deallocation, I had a registered key-value observation on the container property. So, when the object removed itself from the list, KVO called [NSSet setWithObject:removedObject] in order to pass it as part of the change dictionary to the observer callback. This naturally went on the autorelease pool. But oops, we were already in -dealloc of the removed object, so the retain the autoreleased set tried to add was a no-op. Finally, next time through the event loop, that set was freed by the autorelease pool, and tried to call -release on the removed object, but that object had already been fully deallocated. Crash!

Now, a purist will say “stop trying to do things in -dealloc!” Others would point out that GC would bypass this entire problem. Either way, I wanted a simple solution. The problem was an autorelease pool, so just add another one!

- (void)dealloc
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    [[Singleton singleton] removeContainerObject:self];
    [pool release];
    [super dealloc];
}

KVO’s set is no longer deferred-release, and all is well.

As it happens, this uncovered an underlying issue in my code, a design flaw which essentially makes the entire debacle unnecessary because the list management needed to be in other methods rather than -init and -dealloc, but I thought it was an interesting note nonetheless.