Volume Number: 25
Issue Number: 10
Column Tag: The Road to Code

The Road to Code: Look What the Cat Dragged In

What's new in Snow Leopard

by Dave Dribin

It's hard to believe that it's been nearly two years since Mac OS X 10.5, Leopard, was released. The next major version of Mac OS X, version 10.6, code named Snow Leopard, is now upon us. While Apple may have originally touted that Snow Leopard contained only one new feature, this release is as packed full of developer goodness.

It's probably best to work our way up from the bottom and discuss what's new at the language level, first. In Leopard, we got Objective-C 2.0 and garbage collection. With Snow Leopard, we get another very big feature: blocks. A block, sometimes called a closure or lambda in other languages, is similar to a function pointer, except that is can be defined inline and is captures the local stack variables for later use. Blocks can be used in plain C as well as Objective-C, and their syntax is very similar to function pointers. Here's a simple example of function pointers in standard C:

void printJoe(void)
{
    printf("My name is Joe.\n");
}
void printJane(void)
{
    printf("My name is Jane.\n");
}
void printNames(void)
{
    void (*printName)(void) = NULL;
    
    printName = printJoe;
    printName();
    
    printName = printJane;
    printName();
}

The printName variable is a function pointer. The strange syntax is needed to define its expected return type and arguments. In this case, printName is a function pointer that returns void and takes no arguments, a void parameter. It's a pointer just like any other pointer, so we can set it to NULL, just like any pointer. You can assign it any function that matches its signature, i.e. any function that returns nothing and takes no parameters. In the example above, we first assign the printJoe function to the printName variable. Notice that we do not use parentheses on printJoe, since that would actually call the function. Once we assign a non-NULL value to the printName variable, we can use it to call the function it's pointing to, and the syntax looks like an ordinary function call. Thus, this statement calls the function being pointed to:

    printName();

In the first case, this calls the printJoe function. We then assign it again, this time to printJane, and call it again. If we called the printNames function, we would get the following output to the console:

My name is Joe.
My name is Jane.

Function pointers in C are a rather obscure feature that doesn't get used very often. There just aren't a lot of real world uses for them.

Blocks are similar to function pointers, but a lot more flexible. The syntax for block variables is similar to function pointer variables, except that you use a caret (^) instead of a star (*). Here's how we could rewrite printNames using blocks:

void printNames(void)
{
    void (^printName)(void) = NULL;
    
    printName = ^{
        printf("My name is Joe.\n");
    };
    printName();
    
    printName = ^{
        printf("My name is Jane.\n");
    };
    printName();
}

The printName variable is declared using similar syntax. Creating and assigning a block to the printName variable again uses ^.

This demonstrates that you can create a block of code inline, rather than factoring it out into a separate function. Blocks can also take arguments and have a return value:

void doMath(void)
{
    int (^multiply)(int x, int y);
    multiply = ^(int x, int y) {
        return x*y;
    };
    
    printf("Multiply: %d\n", multiply(3, 5));
}

The real benefit of blocks, however, is their ability to capture local stack variables and use them:

void doMath(void)
{
    int (^multiply)(int x);
    int y = 5;
    multiply = ^(int x) {
        return x*y;
    };
    
    printf("Multiply: %d\n", multiply(3));
}

In this case, the y variable is captured and can be used inside the block. This is a contrived example, but we will see an example where the benefit of this becomes more readily apparent.

The previous examples show how blocks can be used from straight C, but many Objective-C APIs have been updated to take advantage of blocks. For example, NSArray has a new method to enumerate its items using a block:

    NSArray * colors = [NSArray arrayWithObjects:
                        @"Red", @"Green", @"Blue", nil];
    [colors enumerateObjectsUsingBlock:
     ^(id color, NSUInteger idx, BOOL *stop) {
        NSLog(@"Color: %@", color);
    }];

Here, we specify a block that gets invoked for every element in the array. This is actually a bit more verbose than the for... in syntax added in Leopard, but there certain things you can do better by enumerating with blocks. For example, you can enumerate in reverse order efficiently. There's also a way to enumerate items concurrently, allowing you to fully exploit multiple cores, if there are no dependencies between each iteration.

Blocks are really good for asynchronous actions. A common pattern in Objective C is to provide a selector to be called when an asynchronous action is finished. This is used in sheets where the selector is called when the sheet is finished. Blocks make this kind of idiom much easier, and NSSavePanel and NSOpenPanel now have a block-based API when using sheets. Here's example code that runs an open panel for text files:

- (IBAction)openTextFiles:(id)sender
{
    NSOpenPanel * panel = [NSOpenPanel openPanel];
    
    NSArray * fileTypes = [NSArray arrayWithObject:@"txt"];
    [panel setAllowedFileTypes:fileTypes];
    
    [panel setAllowsMultipleSelection:YES];
    [panel beginSheetModalForWindow:self.window
                  completionHandler:^(NSInteger result) {
        if (result == NSOKButton) {
            NSArray * filenames = [panel filenames];
            for (NSString * filename in filenames) {
                [self doSomethingWithFile:filename];
            }
        };
    }];
}

The beginSheetForModalWindow: method takes a block as the final argument. The sheet is started and this method returns right away. When the user dismisses the sheet, the completion handler is called. This block takes a single integer argument corresponding to which button was press. In this code, we take some action if the user pressed the Open button. Remember what I said about blocks capturing local variables? This is shown by the ability to use the panel stack and self variables inside the block.

Grand Central Dispatch, or GCD, is a new framework to help developers fully utilize the multiple CPU cores shipping on all Macs. It is built upon blocks and adds what's known as dispatch queues. Dispatch queues are a queue of blocks that take no parameters and return nothing. As you enqueue blocks to a queue, they get executed. Here is a simple example showing you how to add a block to a queue:

    dispatch_async(queue, ^{
        NSLog(@"Async");
    });

This method is asynchronous, meaning it returns right away. The block is then executed on the queue, which may even be a different thread.

GCD provides global queues for dispatching blocks to background threads. Blocks added to the global queue also run concurrently with each other. Here's how you would get the global queue, with the default priority:

    dispatch_queue_t queue =
        dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

Combining these two lines is how you get very easy concurrency.

GCD also provides us with a queue that corresponds to the main thread:

    dispatch_queue_t queue = dispatch_get_main_queue();

Blocks added to the main queue get executed on the main thread. Blocks are also executed serially on the main queue, meaning there is no concurrency and they execute strictly in the order they are added. Using the main queue can replace the old performSelectorOnMainThread: method to shuttle work over to the main thread. It is important to only access AppKit from the main thread, so this makes dealing with these circumstances even easier.

So how can these be used to help bring concurrency to your application? Say you have a method that can take some time to execute. If you executed this on the main thread in response to a button press, there's a good chance you will block the UI thread. When this happens, the user sees the spinning pinwheel icon, and the application becomes unresponsive. Here's some sample code:

- (IBAction)buttonPressed:(id)sender
{
    NSURL * url = [NSURL URLWithString:[_urlField stringValue]];
    NSString * string = [self getStringFromUrl:url];
    [_textField setStringValue:string];
}

In this code, if the getStringFromUrl: method takes a long time to execute because it performs a network operation, it could block the UI thread. Since this is undesirable, the way to deal with this is to execute getStringFromUrl: on a background thread. Of course, we need to set the result on the main thread, since we are putting the result in a text field. Using GCD and blocks, this becomes very easy to do:

- (IBAction)buttonPressed:(id)sender
{
    dispatch_queue_t concurrentQueue =
        dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_queue_t mainQueue = dispatch_get_main_queue();
    NSURL * url = [NSURL URLWithString:[_urlField stringValue]];
    dispatch_async(concurrentQueue, ^{
        NSString * string = [self getStringFromUrl:url];
        dispatch_async(mainQueue, ^{
            [_textField setStringValue:string];
        });
    });
}

First, we grab the URL from the text field on the main thread. Then, we use a global concurrent queue to call the getStringFromUrl: method on a background thread. Finally, we use the main queue to update the UI. This again shows the power of blocks being able to access variables on the stack. For example the url variable is available in the global queue block and the string variable is available on the main queue block.

Writing the equivalent code without GCD and blocks is certainly possible, but it ends up being a lot more verbose. You would need to factor out the code into separate methods and create a thread yourself. Also, you would need to pass the objects as arguments to the methods. In more complicated cases, you often need to create instance variables because the performSelector methods only allow you to pass one or two objects. Blocks and GCD eliminate all of this hassle.

There is quite a bit more to GCD. You can create your own queues, group blocks together, and even replace locks with dispatch queues; however, this should at least provide a hint of how much easier it is to make your application concurrent with GCD.

NSOperation and NSOperationQueue were added in Leopard to help with writing concurrent code, and in Snow Leopard they are written on top of GCD. This means that NSOperationQueue now performs better than it did in Leopard. There is a new block operation subclass, so you can easily turn a block into an operation:

    NSOperation * operation =
        [NSBlockOperation blockOperationWithBlock:^{
            // Do long running task
        }];

There is also a new main operation queue, which is similar to the GCD main dispatch queue. The main operation queue runs its operations serially on the main thread:

    NSOperationQueue * queue = [NSOperationQueue mainQueue];
    [queue addOperationWithBlock:^{
        // Run on the main thread
    }];

This also demonstrates the new addOperationWithBlock: method, which eliminates the need to deal with an NSOperation subclass at all, for simple cases.

In Snow Leopard, the behavior of concurrent operations has changed. A concurrent operation is one that overrides the -isConcurrent method to return YES. Concurrent operations act a little differently in Snow Leopard. The -start method is always called on a background thread. If you used concurrent operations to start asynchronous actions on the main thread, such as starting an NSURLConnection, this may trip you up.

In Leopard, AppKit was available in 64-bit mode for applications that needed the extra memory, however 32-bit applications were still the default. In Snow Leopard, 64-bit mode is preferred to 32-bit on hardware that supports it, and nearly all system applications are available in 64-bit mode, including the Finder, which was rewritten in Cocoa.

There are additional benefits to 64-bit mode over 32-bit beyond access to more memory. Because 64-bit mode is new, Apple was able to break backwards compatibility for the Objective-C application binary interface (ABI) to provide better performance. One example of this is the fact that arguments to functions and methods are passed in registers wherever possible. In 32-bit mode, arguments were always passed on the stack. Using registers can give every function and method call a performance boost. These benefits are nothing new to Snow Leopard, but as all system applications are now running in 64-bit mode, they may feel a bit snappier for this reason alone.

One important point to note is that if you are writing an application that runs on 10.5 and 10.6, you will probably still want to write in 32-bit mode on 10.5. The reason for this is that it's best to use whatever the system default is, unless you have a good reason not to. If your application is the only 64-bit application on a 10.5 machine, your application will be using a lot more memory because it has to use 64-bit versions of all the system frameworks. Much of the memory for the system frameworks is shared amongst all running applications, and if your application is the only 64-bit application, then it cannot take advantage of the memory sharing.

Ideally, your application should run as 32-bit on 10.5 and 64-bit on 10.6. There's actually some trickery you can do in your Info.plist so that your application works this way. Here is a snippet of XML to show how you could set this up:

   <key>LSArchitecturePriority</key>
   <array>
      <string>x86_64</string>
      <string>i386</string>
      <string>ppc</string>
   </array>
   <key>LSMinimumSystemVersionByArchitecture</key>
   <dict>
      <key>x86_64</key>
      <string>10.6</string>
   </dict>

By using the LSMinimumSystemVersionByArch-itecture key, you're telling the OS to use 64-bit mode (x86_64) only on 10.6 and later. Thus 10.5 will still use 32-bit mode (i386).

Of course, this means that your applications will need to actually support 64-bit mode. You don't want to be the only 32-bit application running on Snow Leopard. So if you haven't already, build and test your applications for the x86_64 architecture.

Figure 1: New error bubbles

Some of the Core Data improvements include:

lightweight migrations,

Spotlight integration, and

new fetch operations to tune performance.

Lightweight migrations mean that simple changes to your schema can be handled without any code at all and no mapping model. This is a welcome addition since changing schemas are a part of life. You can still drop back to Leopard's migration for complicated schema changes, but this takes the hassle out of the easy changes.

Core Data now has built-in support for Spotlight integration. Spotlight requires that every "record" have its own file on the file system. This has traditionally been problematic for Core Data databases, since all record data is stored in a single file. To rectify this situation, Core Data provides a mechanism to generate the Spotlight metadata files and keep them automatically up-to-date with the Core Data database.

There are a whole host of new fetch options to help you tune your fetches. The first is the ability to fetch in batches. Previously, you had only two options: fetch the results as managed objects or fetch as faults. For large data sets, where only a few objects are displayed in the UI, fetching all results as managed objects uses more memory than needed. On the other hand, fetching results as faults means every item will need to be faulted in as it is displayed. Using batch fetching allows you to fetch a subset of the results as managed objects. This is the best of both worlds. By tuning the batch size, you can ensure that just enough data to be displayed in the UI is fetched, but still be memory efficient.

Another technique for increasing fetch performance is to use partial faults. If the UI is only displaying a few of the attributes of a managed object, it is wasteful to populate all attributes from the database. Partial faults allow you to read in only the data you need, thus saving I/O and memory.

One final interesting fetch option is the ability to fetch results as a dictionary. This can be very handy for read-only interfaces. Not only does this provide the ability to only pull back the data you are interested in, similar to partial fetches, but it also allows you to use aggregates and distinct values to push more processing down to the SQLite level.

The pasteboard and system services have gotten a nice upgrade in Snow Leopard. You now interact with the pasteboard using standard Universal Type Identifiers (UTIs). This provides consistency with the rest of the operating system, where UTIs have been used throughout, instead of the old constants like NSStringPboardType. You can also place multiple items on the pasteboard, which is something only Carbon applications could do. While the old API is still available, there are new methods on NSPasteboard to support these new features, and any new application should use them.

System services have also gotten an overhaul for Snow Leopard. System services encompass the Services menu in each application. In previous versions of Mac OS X, the Services menu showed all services, even ones that were disabled. Thus, the menu got very large and unwieldy. Also, a service could register a hot key that would, in effect, become a global hot key, because services are available in all applications. Unfortunately, the user had no way to disable or change these shortcuts. Both deficiencies have been addressed in Snow Leopard.

The Services menu now only lists services that you can actually use. Those that are not valid for the current context are not shown at all. Furthermore, the user can edit the keyboard shortcuts in System Preferences. As an extra bonus, services can show up in the context menu. This provides a method to extend the functionality of applications without resorting to a plug-in. This will be especially useful for the new Finder, which won't load any plug-ins for 10.6.

Finally, some views that have seen improvement in Snow Leopard are NSImage, NSBrowser, and NSCollectionView. Be sure to read the release notes if you want to find out more information.

What OS upgrade would be complete without updates to the developer tools? The biggest winners in Snow Leopard are Xcode and Instruments.

Xcode gets a bit of a face-lift. The error bubbles introduced in Leopard have been refined to be less intrusive, as shown in Figure 1. The build results window has been completely revamped to help you focus on the results and also deal with large build logs.

The code completion has been improved and is more context-aware. The Open Quickly dialog seems to be much faster.

You can rename a project. Since this isn't as easy as renaming the .xcodeproj file, Xcode now renaming provides you with a wizard so you can rename other parts of your project that may also need to be renamed such as targets and menu items, too.

You can also fill in the company name as a per-project setting. While Xcode 3.1 used your company name from your Address Book contact, this allows for more precise control. This is great for people who work for multiple organizations. So there's really no more excuse to have __MyCompanyName__ in your header comments.

Xcode now has built-in support for the Clang Static Analyzer. The Clang Static Analyzer runs static analysis on your code to find many common errors that the compiler does not normally find, even with all warnings enabled. The analysis results show up in the Build Results window, just like other errors. Running the static analyzer for the first time is very eye opening. It'll find all sorts of bugs that have most likely been lurking for a while, and I highly recommend you get into the habit of running the static analyzer periodically.

Instruments has also been vastly improved in Snow Leopard. The following instruments have been added:

The Time Profiler is a statistical sampler, similar to Shark, and allows you to pinpoint performance hotspots. It is very low impact and provides more precise timing data by sampling in the kernel.

The Dispatch, Multicore, and Threads instruments are new instruments that help get the most out of GCD and threads. If you're trying to make your application more concurrent and are not seeing the benefits you expect, these instruments can help you.

The Zombies instrument help you find places were you use objects after they are deallocated. Using over-released objects typically cause crashes, and can be hard to track down. The system helps you track over-released objects by turning your object into a zombie object, instead of actually freeing the memory. Any messages called on the zombie object trigger Instruments, complete with a stack trace. Coupled with the Object Alloc instrument, you can know which object was being over-released. This instrument takes place of the NSZombiesEnabled environment variable and makes it easier to track zombies with a nice GUI.

Finally, the Object Graph and Garbage Collection objects help you tune your garbage collection enabled applications. While garbage collection does help deal with memory management, it's still possible to leak memory and use more memory than you intend. Usually this is due to an object being referenced after it is no longer needed. The Object Graph instrument helps pinpoint these cases so you can see what is preventing an object from being collected and freed.

This is a relatively brief overview of what's new for developers in Snow Leopard, and it's just the tip of the iceberg. Be sure to read all the release notes to learn about all of the goodies.

Dave Dribin has been writing professional software for over eleven years. After five years programming embedded C in the telecom industry and a brief stint riding the Internet bubble, he decided to venture out on his own. Since 2001, he has been providing independent consulting services, and in 2006, he founded Bit Maki, Inc. Find out more at http://www.bitmaki.com/ and http://www.dribin.org/dave/.