In particular, the Places feature allows you to import GPS data from iPhone photos or from GPS data captured by pretty much any device that can spew a standard GPX format data file.

Tagging from the iPhone is straightforward. With the iPhone connected to your computer, go to Places in Aperture and then select Import from iPhone Photos…. Aperture will then display all the photos on your iPhone that have GPS metadata and you can pick the photos from which the GPS data is to be imported. Once picked, Aperture will apply the GPS data to photos taken near the same time as the imported data.

However, one issue with the iPhone is that it really isn’t a terribly good GPS logging device. Using it as one eats the battery and the data generated often has holes. And, because the iPhone uses A-GPS (GPS assisted by cellular signal), it doesn’t work at all when hiking in areas without cell signal. Apparently, I’m mistaken about A-GPS — it should fall back to regular GPS behavior. My experience, though, is that the iPhone just isn’t a terribly good GPS device when it doesn’t have a cell signal and has often been off by miles when in the hinterlands. It works great when on the road or near cities, though.

Dragging a photo onto a track. Note that my camera’s clock was set correctly.

Importing a raw GPS Track is a slightly more involved process and, at first blush, doesn’t entirely seem as easy as it could be. But there is a good reason for the way it works; clocks on cameras generally suck and, thus, there is a need to effectively timeshift imported photos vs. the GPS data.

When you import a GPS track, the Tracks and Waypoints submenu will be populated with the various segments of GPS track data imported from the log. Once you select a GPS track that includes a location for a photo that you want to geotag, drag the photo to the exact location on the track where the photo was taken. Aperture will display the offset in time between the photo’s timestamp and the GPS data. When you drop the photo, Aperture will ask if you want to assign GPS metadata to all photos taken during the (potentially offset) duration of the GPS track.

Done. Photos geotagged. And, if you haven’t happened to reset your camera’s clock recently, you’ll probably be chagrined and amazed to know exactly how poorly your camera keeps time!

Of course, you need a source of GPS metadata. And this is where your fuzzy happy generally intuitive and “just works” experience ends. Frankly, the state of GPS support on the Mac just flat out sucks outside of a handful of navigation oriented devices.

After purchasing and returning two different devices, I finally settled on the Qstarz BT-Q1300S.

First, the good: the Q1300S has about a 15 hour battery life, recharges conveniently off of USB, and is conveniently small in size. Once you deal with the shenanigans that I’ll describe below, the unit “just works”. The LED indicators on the front are pretty straightforward. Overall, the passive industrial design — the case, the indicators, the static elements — are quite solid and attractive.

Now, reality:

Physically, the device is small and conveniently sized. The strap is too tight and, thus, doesn’t really swivel much. I can easily replace that.

There are two additional flaws that can’t be fixed. First, the unit uses a single button for power and other functions. It is of poor quality and, after only a few uses, is starting to stick. A co-worker with the same device has the same problem.

Second, the mini-USB connector is covered by a rubber shield (good!), but that shield flips open to cover the power button (which you need to get to) and actually gets in the way of sticking in the USB cable! Dumb.

From a User Experience perspective, the device is a train wreck. To turn on, hold the power button for 4 seconds. It boots and then it starts logging (the LEDs on the front do a pretty good job of giving status, though “solid” vs. “blinking” for “looking for GPS” vs. “GPS signal good” is non-obvious). To turn off logging (convenient for downloading or for just using as a BlueTooth data source), hold down the button two seconds. To turn off, hold down the button for four seconds. There is very little visual feedback during this process.

Horrible. Combined with a button that sticks and it is close to unusable. I would much rather have two buttons — power and mode — without the need to hold either down for any length of time.

To download data, requires that the device be on. Plugging in the device causes the Battery light to come on — almost looking like a power indicator. Of course, if you turn on the device, it’ll default to logging data. Expect to always have a dozen or so data points from wherever you happened to be when you downloaded the data. Remember that rubber gasket thingy from the USB port I mentioned earlier? The one that covers the power button? Yes, it is in the way if you need to turn on the device after plugging it in.

Why the damned thing doesn’t simply turn on when USB power is applied is beyond me. Better yet, why not let the device mount as a flash drive (some units do, but they had other flaws that made them even worse than the QStarz).

Since it doesn’t mount as a drive, that means you need some software to retrieve data from the device. Thankfully, HoudahGPS to the rescue. Once configured, it works quite well. Plug in the unit, make sure it is powered up, and then click the Acquire button. Done.

Configuring the device from a Mac is… unfortunate.

The QStarz device is based on the MTK chipset. This is a fairly standard chipset and, thus, there exists open source software for interacting with it. In particular, you’ll want BT747. It is a Java application that can configure, download, and otherwise manage an MTK based device (amongst other). Via the BT747 software, you can configure the sampling rate of the device. It defaults to once-a-second, but 2 or 3 times a second is useful for tracking relatively fast moving motion that changes directions quickly; biking or driving, for example.

If you want to communicate with the QStarz via BlueTooth (and maybe via USB — I didn’t try), go to the Finder and check the Open in 32-bit mode option.

Bottom line; with geotagging of photos becoming pretty much ubiquitous across both photo organization tools and the various websites (flickr, etc), it is only a matter of time — 12 to 18 months, I would guess — until pretty much every camera has GPS built in. Until then, the QStarz 1300S fills the gap. Not nicely, but it does work.

Heck, not only can I take can take a photo of Roger and one of the very few phone booths left in the state, but I can even show you exactly where it is (turn on “Hybrid” mode to see more than a green blob on the map)!

I am concerned about build quality. The company does monitor twitter, is aware of my power button issue, and is responding extremely proactively (so far). I’m impressed and, frankly, if QStarz comes through with their promise to replace my device, it will go far to assuage my disdain for the device.

Now, if QStarz would produce a useful — simple — Mac client, that would make me even happier.

1. objc_msgSend() Tour Part 1: The Road Map
2. objc_msgSend() Tour Part 2: Setting the Stage
3. objc_msgSend() Tour Part 3: The Fast Path
4. objc_msgSend() Tour Part 4: Method Lookup & Some Odds and Ends

In the first three parts, I gave an overview, explained a bit of the ABI used by Objective-C, and took a near instruction by instruction tour of what happens on the fast path of Objective-C method dispatch. By fast path, I mean what happens 99.9% of the time; a very fast, no overhead, no function call, no locking, set of instructions that grabs the method implementation from the cache and does a tail-call jump to that implementation.

The slow path is used rarely. As little as once per unique selector invoked per class with a goal of filling the cache such that the slow path is never used again for that selector/class combination. A handful of operations will cause a class’s cache to be flushed; method swizzling, category loading, and the like.

Note that during +initialize, methods won’t always be cached. Yet another reason to not do any real work during +initialize!In part 3, the cache lookup loop contained a NULL check and, if NULL was encountered in the cache, then the code jumped to a cache miss label. It looked like this (with the original source interleaved):

// 	movq	buckets(%a5, %a4), %r11	// method = cache->buckets[bytes/8]
0x0000512d  movq        0x10(%r8,%rcx),%r11
// 	testq	%r11, %r11			// if (method == NULL)
0x00005132  testq       %r11,%r11
// 	je	LCacheMiss$1			//   goto cacheMissLabel
0x00005135  je          0x0000515c

Note that the disassembly shows that the cache miss label is located at address 0x0000515c. Not at all coincidentally, that is exactly where this particular post’s tour starts. Namely, what happens when the cache lookup misses and the cache must be filled.

When I referred to this code path as the slow path, I wasn’t kidding! This is the one spot where the messenger actually makes a call into a C function which is then responsible for traipsing about the runtime metadata to resolve the method and fill the cache. Beyond that, the C function — _class_lookupMethodAndLoadCache() — is also responsible for ensuring that any +initialize methods of the class (and superclasses) are invoked prior to the method itself being invoked. This also implies that objc_msgSend() must effectively be recursively safe across this particular call site.

And that requirement leads to the need to preserve all of the various registers and push a stack from for the purposes of making the call. This is actually considerably more involved than a normal call site because the runtime is effectively hijacking the method invocation call to call something totally alien to the original method’s implementation!

0x0000515c  pushq       %rbp
0x0000515d  movq        %rsp,%rbp
0x00005160  subq        $0x000000c0,%rsp

The above saves the current stack pointer and then bumps the stack pointer down by 0xc0 (192) bytes. This is to make room for…

0x00005167  movdqa      %xmm0,0xffffff40(%rbp)
0x0000516f  movdqa      %xmm1,0xffffff50(%rbp)
0x00005177  movdqa      %xmm2,0xffffff60(%rbp)
0x0000517f  movdqa      %xmm3,0xffffff70(%rbp)
0x00005187  movdqa      %xmm4,0x80(%rbp)
0x0000518c  movdqa      %xmm5,0x90(%rbp)
0x00005191  movdqa      %xmm6,0xa0(%rbp)
0x00005196  movdqa      %xmm7,0xb0(%rbp)
0x0000519b  movq        %r10,0xc0(%rbp)
0x0000519f  movq        %rax,0xc8(%rbp)
0x000051a3  movq        %rdi,0xd0(%rbp)
0x000051a7  movq        %rsi,0xd8(%rbp)
0x000051ab  movq        %rdx,0xe0(%rbp)

… all of the registers that need to be pushed onto the stack. Note that %r10 doesn’t actually have to be pushed — it is a scratch register. Someday, %r10 might disappear from that instruction stream.

0x000051af  movq        (%rdi),%rdi
0x000051b2  movq        %rsi,%rsi
0x000051b5  callq       __class_lookupMethodAndLoadCache
0x000051ba  movq        %rax,%r11

Now we get to the actual function call itself.

IMP _class_lookupMethodAndLoadCache(Class cls, SEL sel)

You can find the declaration and implementation in objc-class.m.

If you had read Greg’s “So You Crashed in Objc_MsgSend”, you would know that %rdi contains the first argument and %rsi contains the second argument when calling a function.

The movq (%rdi),%rdi instruction dereferences the contents of %rdi and shoves the result into %rdi. Effectively, it grabs the isa of the targeted object and passes it as the first parameter to the function. In the case of an instance, this will be the class of the instance. In the case of a class, it will be the metaclass of the class.

Frankly, the movq %rsi,%rsi instruction makes no sense to me. It is clearly loading the second argument, but it is effectively a no-op since the source and destination are the same and the movq instruction doesn’t set or reset any of the processor’s status flags. Then again, I could easily be missing something.

The movq %rsi,%rsi instruction looks like nonsense in this context. It is here, but I forgot that this is actually an expanded macro (thanks, Greg, for the explanation!). If we return to the original source and grab the line from the macro, you will see:

	movq	$0, %a1
	movq	$1, %a2
	call	__class_lookupMethodAndLoadCache

The movq $1, %a2 instruction generates the movq %rsi,%rsi instruction when expanded. Note that the source is a parameter to the macro, though! For other variants of objc_msgSend() — for the ones that return values on the stack and not in registers — the “self” argument is actually in %a2 and “_cmd” is in %a3. Thus, the reason for the sometimes meaningless instruction.

If this particular codepath was performance sensitive to the degree where one or two instructions matters, the assembly macro language does have conditionals that could be used to eliminate the instruction when source and destination are the same.

Finally, the return value is passed back in register %rax and is stowed away into register %r11 for use shortly.

0x000051bd  movdqa      0xffffff40(%rbp),%xmm0
0x000051c5  movdqa      0xffffff50(%rbp),%xmm1
0x000051cd  movdqa      0xffffff60(%rbp),%xmm2
0x000051d5  movdqa      0xffffff70(%rbp),%xmm3
0x000051dd  movdqa      0x80(%rbp),%xmm4
0x000051e2  movdqa      0x90(%rbp),%xmm5
0x000051e7  movdqa      0xa0(%rbp),%xmm6
0x000051ec  movdqa      0xb0(%rbp),%xmm7
0x000051f1  movq        0xc0(%rbp),%r10
0x000051f5  movq        0xc8(%rbp),%rax
0x000051f9  movq        0xd0(%rbp),%rdi
0x000051fd  movq        0xd8(%rbp),%rsi
0x00005201  movq        0xe0(%rbp),%rdx
0x00005205  movq        0xe8(%rbp),%rcx
0x00005209  movq        0xf0(%rbp),%r8
0x0000520d  movq        0xf8(%rbp),%r9
0x00005211  movq        %rbp,%rsp
0x00005214  popq        %rbp

And… all these instructions are simply to restore all the registers back to the state they were in prior to the call to _class_lookupMethodAndLoadCache().



0x00005215  cmpq        %r11,%r11
0x00005218  jmp         *%r11d

Finally, dispatch! The cmpq resets the status registers to indicate a non-structure return value. In other words, the above two instructions are no longer contained in the method lookup macro, but are found in the messenger itself (and will be different from the other messengers).

Note that _class_lookupMethodAndLoadCache() will never return NULL and, hence no need for a NULL check above. If a method isn’t found, then _class_lookupMethodAndLoadCache() returns the address of the forwarding handler. Because forwarding may actually come into play often, the forwarding handler is actually put into the cache such that future invocations can leverage the fast path.

That is it; that is both the fast and the slow path of method invocation.

But what are these instructions?? There appear to be some leftovers!?!

0x0000521b  movq        0x000b32be(%rip),%rdi
0x00005222  testq       %rdi,%rdi
0x00005225  jneq        0x0000510a
0x0000522b  movq        $0x00000000,%rax
0x00005232  movq        $0x00000000,%rdx
0x00005239  xorps       %xmm0,%xmm0
0x0000523c  xorps       %xmm1,%xmm1
0x0000523f  ret

Way back as the very first two instructions to objc_msgSend() there was a nil check. If the target of method invocation is nil, then jeq 0x0000521b.

This is the nil handling code. The last five instructions — the two movq, two xorps, and ret — take care of actually zeroing out all of the return value registers and returning control to the caller. This also explains why not some types of return values are undefined on message-to-nil. Message-to-nil can only safely zero out values that are returned in the return registers. There isn’t enough metadata in the C ABI to know how much of the stack to zero for values returned on the stack.

THe first three instructions load the value — movq 0x000b32be(%rip),%rdi — contained in the _objc_nilReceiver global into the register %rdi. The testq %rdi,%rdi instruction sets the processor’s zero flag in the status register if the value contained in %rdi is zero. The jneq 0x0000510a instruction will jump if the value is not zero. That address is actually back into objc_msgSend and, in particular, basically does a dispatch to the nil message receiver with the same selector.

I wrote up how to write your own nil receiver quite some time ago.

0x00005240  movq        %rdi,%rax
0x00005243  ret

These final two instructions are what happens when you invoke one of the ignored selectors under GC. It effectively causes the method to return self; by moving the target of the method call from the first argument register %rdi into the return value register %rax.

Note that this is also the reason why -retainCount returns such an outrageous value under GC; it is the address of the object.

There you have it. That is every instruction that may be executed in objc_msgSend() from beginning to end.

Quite often, the questioner can actually use Instruments just fine, but simply lacks the know-how or hasn’t tried in a while and doesn’t realize that Instruments has improved significantly with each release of the developer tools. No, really, Instruments is a fantastic tool and I use it whenever I can; what you see below is for the exceptional case, not the norm.

There are cases where using Instruments is either inconvenient or impractical. Namely, trying to track down an intermittent crasher or trying to gain insight into memory leaks over a long running session will create a prohibitively large dataset for Instruments to process (Instruments allows for much more detailed analysis of the object graph and this analysis loads a lot more data than the tools I’ll demonstrate below).

Thus, it is helpful to be familiar with the rather powerful set of tools available from the command line and within the debugger.

Almost always, you are going to want to enable a bit of additional data via the malloc infrastructure. Have a look at the malloc(3) man page. There is an entire section devoted to ENVIRONMENT variables and there are a handful of extremely useful variables!

First and foremost, you are almost always going to want to use MallocStackLoggingNoCompact. When enabled, malloc stack logging writes the stack trace of every allocation and free event to an efficiently compact binary file in /tmp/ (it used to be in memory and, thus, used to be a great way to exhaust heap. No longer!!). Unfortunately, it doesn’t record the retain and release events, but simply knowing where the object was allocated is generally quite useful (it is generally relatively easy to track down who retained an object once you know which object it is). Under GC, you can set the AUTO_REFERENCE_COUNT_LOGGING and CFRetain/CFRelease events will be logged to the malloc history.

You can then use the malloc_history command line tool to query for all events related to a particular address in memory.

While malloc_history requires that the process still exists, it doesn’t have to be running! If you run your app under gdb, you can still use malloc_history to query the application even when it is stopped in the debugger!

Speaking of gdb, you can use the info malloc command in gdb to query the same information. Under GC, the info gc-roots and info gc-referers commands can be used to interrogate the collector for information about the connectivity of the object graph in your running application.

If you enable zombies via setting the NSZombieEnabled environment variable to YES, the address spewed in the error message when messaging a zombie can be passed directly to malloc_history.

The leaks command line tool scans memory and detects leaks in the form of allocations of memory for which the address to that memory is not stored anywhere else within the application. The leaks tool has been vastly improved in the Snow Leopard release of the Xcode tools; it is much much faster and spits out false positives almost never. It is still possible to have a leak that leaks cannot detect, of course. And, remember, even if you can still reach memory, it is still a total waste if you never use that memory’s contents again!

So, that is a brief summary of the state of command line memory debugging on Mac OS X as of Snow Leopard. Of course, that’s just a bunch of words. How about an example?

The code:

#import <Foundation/Foundation.h>
int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    BOOL doLeak = !!getenv("leak");
    id o = [NSObject new];
    o = [NSMutableSet new];
    if (doLeak) {
        // leak some memory
        [o retain];
        [o release];
        [o retain];
        [o autorelease];
        o = @"Uncle";
    } else {
        // message an overreleased object
        [o autorelease];
        [o release];
        o = @"Bob";
    }
    [pool drain];
    sleep(4242424242);
    return 0;
}

If you create a standard Cocoa Command Line Tool project and paste the above into the main file, you will have effectively created the tool I used for the below examples.

Detecting Leaks

To test for leaks, you’ll want to use the leaks command line tool, generally.

You can either set the environment variables in the shell and then run the command or do it all at once:

env MallocStackLoggingNoCompact=YES leak=YES /tmp/bbum-products/Debug/MemoryMunchies

Or, in gdb you can use the set env to set the environment variables prior to a run.

In any case, when you run the tool with the environment variables set as above, you’ll see spewage like this:

MemoryMunchies(56604) malloc: recording malloc stacks to disk using standard recorder
MemoryMunchies(56604) malloc: stack logging compaction turned off; size of log files on disk can increase rapidly
MemoryMunchies(56604) malloc: stack logs being written into /tmp/stack-logs.56604.MemoryMunchies.z05dcb.index

Now, you can use the leaks command to scan for leaks:

% leaks 56604
Process 56604: 845 nodes malloced for 204 KB
Process 56604: 2 leaks for 64 total leaked bytes.
Leak: 0x10010c8e0  size=48  zone: DefaultMallocZone_0x100004000	instance of 'NSCFSet', type ObjC, implemented in Foundation
	0x70d06df8 0x00007fff 0x00001080 0x00000001 	.m.p............
	0x00000001 0x00000000 0x00000000 0x00010000 	................
	0x70ef7268 0x00007fff 0x00000000 0x00000000 	hr.p............
	Call stack: [thread 0x7fff7087cbe0]: | start | main | -[__NSPlaceholderSet initWithCapacity:]
| CFSetCreateMutable | CFBasicHashCreate | _CFRuntimeCreateInstance
| malloc_zone_malloc
Leak: 0x100108ee0  size=16  zone: DefaultMallocZone_0x100004000	instance of 'NSObject', type ObjC, implemented in CoreFoundation
	0x70f124a8 0x00007fff 0x00000000 0x00000000 	.$.p............
	Call stack: [thread 0x7fff7087cbe0]: | start | main | +[NSObject(NSObject) new]
| +[NSObject(NSObject) allocWithZone:] | _internal_class_createInstanceFromZone
| calloc | malloc_zone_calloc

Note that there are actually two leaks here! I had inadvertently left in an extra object allocation as I hacked up that bit of code! Oops.

Or, if I had used Object Alloc in Instruments to grab the address of an interesting object or if I had an NSLog() somewhere that dumped the address of an interesting object (use %p to print pointers nicely), then I could use the malloc_history command to find more information:

% malloc_history 56604 0x10010c8e0
ALLOC 0x10010c8e0-0x10010c90f [size=48]: thread_7fff7087cbe0 |start | main
| -[__NSPlaceholderSet initWithCapacity:] | CFSetCreateMutable | CFBasicHashCreate
| _CFRuntimeCreateInstance | malloc_zone_malloc

In any case, both leaks and malloc_history make it abundantly clear that the allocation event occurred in the main() function. You will quickly learn to ignore the implementation details of the frameworks that these tools expose.

Note that it is quite helpful to enable scribbling via the Malloc environment variables. This will overwrite memory with a known set of non-pointer-esque values upon allocation and deallocation, thus preventing stale data from hiding leaks.

Debugging Crashes

Just like MallocStackLoggingNoCompact, zombies can be enabled via an environment variable; NSZombieEnabled. Or more specifically:

env MallocStackLoggingNoCompact=YES NSZombieEnabled=YES /tmp/bbum-products/Debug/MemoryMunchies

Of course, the app just crashes, leaving you without a process to interrogate. The log files in /tmp/ can’t be interrogated without the process still around.

So, we need to run it in gdb. Being lazy, I just do:

env MallocStackLoggingNoCompact=YES NSZombieEnabled=YES gdb /tmp/bbum-products/Debug/MemoryMunchies

There’ll be a bunch of malloc spewage as various sub-processes are launched and reaped. It can be safely ignored. Or, if you want, you could set up the instance variables in gdb:

% gdb /tmp/bbum-products/Debug/MemoryMunchies
(gdb) set env MallocStackLoggingNoCompact=YES
(gdb) set env NSZombieEnabled=YES
(gdb) r
Reading symbols for shared libraries .++++....................... done
MemoryMunchies(57523) malloc: recording malloc stacks to disk using standard recorder
MemoryMunchies(57523) malloc: stack logging compaction turned off; size of log files on disk can increase rapidly
MemoryMunchies(57523) malloc: stack logs being written into /tmp/stack-logs.57523.MemoryMunchies.E2tMo1.index
2010-01-10 16:49:47.564 MemoryMunchies[57523:903] *** -[CFSet release]: message sent to deallocated instance 0x10010d680
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fff880ede36 in ___forwarding___ ()
(gdb)

At this point, the malloc_history command line tool will still work just fine. However, you can also interrogate malloc state from within gdb itself:

(gdb) info malloc 0x10010d680
Alloc: Block address: 0x000000010010d680 length: 48
Stack - pthread: 0x7fff7087cbe0 number of frames: 7
    0: 0x7fff84b4ea6e in malloc_zone_malloc
    1: 0x7fff8806e445 in _CFRuntimeCreateInstance
    2: 0x7fff8806e230 in CFBasicHashCreate
    3: 0x7fff8808af01 in CFSetCreateMutable
    4: 0x7fff880c809e in -[__NSPlaceholderSet initWithCapacity:]
    5: 0x100000e02 in main at /tmp/MemoryMunchies/MemoryMunchies.m:7
    6: 0x100000d70 in start

Note that if there are multiple allocation events at that address, the events will be printed in chronological order. That is, oldest — and most interesting — events will be last.

1. objc_msgSend() Tour Part 1: The Road Map
2. objc_msgSend() Tour Part 2: Setting the Stage
3. objc_msgSend() Tour Part 3: The Fast Path
4. objc_msgSend() Tour Part 4: Method Lookup & Some Odds and Ends

In any case, with the foundation set — with the id of the object to be targeted in %rdi and the selector of the method to be invoked in %rsi — we can jump into objc_msgSend() and understand exactly what happens instruction by instruction. Or more specifically, the compiler issues a call into objc_msgSend() (which sets up a stackframe for objc_msgSend() which, through tail call optimization, turns into the stackframe for the called method) and the method implementation that objc_msgSend() jumps to will issue a ret instruction to unwind the stack back to the original caller’s frame.

It is pretty easy to correlate the disassembly with the comments and code in the original source file. However, if you ever need to step through the messenger (si steps by instruction in gdb), this will be easier to follow as this is closer to the reality during a debug session.

For almost all method dispatches, dispatch takes what is called the “fast path”. That is, objc_msgSend() finds the implementation in the method cache and passes control to the implementation. Since this is the most common path, it is a good opportunity to break the tour of objc_msgSend() into two parts; the fast path and the slow path (with administrivia).

1. Check for ignored selectors (GC) and short-circuit.

   // this is the first instruction of objc_msgSend
   0x000050f4  cmpq        $0xfffeb010,%rsi
   0x000050fb  jeq         0x00005240                    return;
   

   The cmpq instruction compares the selector of the method call in register %rsi with the value $0xfffeb010. If equal, then a jump to a couple of instruction below is made. Those instructions effectively return self to the caller as the result of the message send.

   Under GC, the selectors retain, release, autorelease, retainCount and dealloc are re-mapped to the ignored selector. Thus, when any of these methods are invoked under GC, objc_msgSend() very quickly returns self without otherwise doing anything. In dual-mode code, a great percentage of method calls are these ignored selectors and, thus, this makes dual-mode code faster (while not significantly penalizing non-GC code; a fraction of a percent overhead in a typical application).

2. Check for nil target.

0x00005101  testq       %rdi,%rdi
0x00005104  jeq         0x0000521b

The testq instruction is effectively an AND of the operand without storing the resulting bits. “Odd”, you say, “why AND something with itself?”. As it turns out, this is the fastest way to test to see if something is 0. Effectively, this is testing the target of the method invocation — the self parameter — to see if it is zero. If it is zero, the zero status flag (a bit in the CPU’s status register) will be set and the JEQ or jump if equal will check the zero flag and make the jump if it is set.

What happens at 0x0000521b is explained below.

3. Find the IMP on the class of the target and jump to it

0x0000510a  movq        (%rdi),%r11

Now we are into the actual dispatch process. The first step is to grab the class of the target object. To do this, the contents of register %rdi are dereferenced and the result is put into %r11. Remember that the first instance variable in NSObject is the object’s isa pointer where the isa is really just a pointer to the class of the object!

Thus, this code grabs a pointer to the class of the object (or the metaclass of the class, if we are messaging a class object) and shoves it into %r11.

Once we have that, the search is on!

1. Search the class’s method cache for the method IMP

This next set of instructions is actually the CacheLookup macro, if you are looking at the original source file.

0x0000510d  movq        %rcx,0xe0(%rsp)
0x00005112  movq        %r8,0xe8(%rsp)
0x00005117  movq        %r9,0xf0(%rsp)

Any time you see a chunk of code that involves a sequence of movq operations with the source operand being registers and the destination being a series of (%rsp) relative destinations, you can pretty much assume that the contents of the registers are being pushed onto the stack for preservation and that you’ll find pretty much the exact same sequence of instructions with operands reversed near the end of the code block.

In this case, it is preserving registers %r9, %r8 and %rcx. Most likely because those registers are going to be used during cache lookup!

And this is the actual cache lookup code. It is rather dense.

0x0000511c  movq        0x10(%r11),%r8
0x00005120  movl        (%r8),%r9d
0x00005123  shlq        $0x03,%r9
0x00005127  movq        %rsi,%rcx
0x0000512a  andq        %r9,%rcx
0x0000512d  movq        0x10(%r8,%rcx),%r11
0x00005132  testq       %r11,%r11
0x00005135  je          0x0000515c
0x00005137  addq        $0x08,%rcx
0x0000513b  andq        %r9,%rcx
0x0000513e  cmpq        (%r11),%rsi
0x00005141  jne         0x0000512d

The source, though, is not quite so dense. The above is produced by this bit of assembly in a macro:

	movq	cache(%r11), %a5 // cache = class->cache
	//
	movl	mask(%a5), %a6d
	shlq	$$3, %a6		 // %a6 = cache->mask < < 3
	mov	$0, %a4			     // bytes = sel
	andq	%a6, %a4		 // bytes &= (mask << 3)

This grabs the cache out of the class and then sets up the various bits used to look in the cache for the method entry corresponding to the selector. The "method triplet" alluded to near the end is a triplet of data containing the selector, the IMP (the function pointer that is the method's implementation), and a C string containing type identifiers for the arguments (and return value) of the method. The goal of the following code is to find that triplet or jump to the code that loads the cache (the slow path).

	//
	// search the receiver's cache
	// r11 = method (soon)
	// a4 = bytes
	// a5 = cache
	// a6 = mask < < 3
	// $0 = sel
LMsgSendProbeCache_$1:
	movq	buckets(%a5, %a4), %r11	// method = cache->buckets[bytes/8]
	testq	%r11, %r11			// if (method == NULL)
	je	LCacheMiss$1			//   goto cacheMissLabel
	//
	addq	$$8, %a4			// bytes += 8
	andq	%a6, %a4			// bytes &= (mask < < 3)
	cmpq	method_name(%r11), $0		// if (method_name != sel)
	jne	LMsgSendProbeCache_$1	//   goto loop
	//
	// cache hit, r11 = method triplet
	//

This is the actual cache lookup code. It loops across the cache and searches for an entry that has the same SEL as the desired selector. Note that the selector is a C string, but the selectors are also uniqued, thus allowing the cache lookup to simply compare the string address -- the SEL -- with the one in the cache entry (the cmpq instruction). If a NULL is encountered, the cache has been exhausted and, thus, execution jumps to the cache miss handler (the LCacheMiss$1 label).

This assembly looks a little different than most because it is actually a macro and, thus, is expanded into the instruction stream when used. Thus, when you see things like $0 and $1 those are actually the parameters passed to the macro. Because jumping to a label is a common task and because the macro is expanded multiple times, the label contains an argument such that the label can be made unique per use.

0x00005143  movq        0xe0(%rsp),%rcx
0x00005148  movq        0xe8(%rsp),%r8
0x0000514d  movq        0xf0(%rsp),%r9

Restore the previously preserved preserved register values.

0x00005152  movq        0x10(%r11),%r11
0x00005156  cmpq        %r11,%r11
0x00005159  jmp         *%r11d

IMP was found! Or, actually, the address of the structure containing the cache entry for the method — the method triplet — was put into %r11. The movq with source 0x10(%r11) dereferences the address in %r11 and copies a quad-words worth of data from that address plus an offset of 0x10, which is where the IMP is stored.

jmp is an unconditional jump. The IMP that was stored into %r11 will be jumped to. So, why the comparison-to-same without testing in the line prior? That instruction clears and sets various status flags that are used by the x86_64 ABI to determine what kind of call is being made.

If you were to look at the source, you would see the comment // set nonstret (eq) for forwarding. “nonstret” refers to non-structure return. The Objective-C forwarding mechanism needs to know whether the method returns a structure because, if so, the self and _cmd arguments will be in different registers. Normally, the C compiler takes care of these shenanigans automatically (including when to turn method calls into calls to objc_msgSend_stret() or objc_msgSend_fpret()), but the forwarding mechanism has to be able to take apart the stack frame and, thus, needs to have a means of detecting which function ABI is in use.

Greg Parker, as often is the case, has a brilliant post discussion why objc_msgSend_stret() exists. There is also — and equally as well described on Greg’s weblog — objc_msgSend_fpret() that is used to handle certain kinds of floats/double (the set changes per architecture).

What follows is the rest of the instruction stream that is used to handle the “slow path”. That is, is used to fully resolve methods when not found in the cache.

1. objc_msgSend() Tour Part 1: The Road Map
2. objc_msgSend() Tour Part 2: Setting the Stage
3. objc_msgSend() Tour Part 3: The Fast Path
4. objc_msgSend() Tour Part 4: Method Lookup & Some Odds and Ends

Objective-C is, ultimately, a simple set of extensions to C that provide an object oriented coding and runtime model. Objective-C fully embraces C and leverages the C calling ABI throughout. Every method call is really just a C function call with objc_msgSend() acting as the preamble that figures out exactly which C function — which method — to call!

Thus, it is helpful to understand how objc_msgSend() is called and how that relates to C. That is, how does the compiler translate [someObject doSomething: 0x2a] into a call.

What follows is a bit of code that makes a [totally bogus] simple method call followed by the assembly generated.

Code:
@interface NSObject(foo)
- (id) doSomething: (NSUInteger) index;
@end
...
    NSObject *b;
    NSArray *a;
    b = [a doSomething: 0x2a]; // line 11
Assembly:
    .loc 1 11 0
    movq	-16(%rbp), %rdi
    movq	L_OBJC_SELECTOR_REFERENCES_0(%rip), %rsi
    movl	$42, %edx
    call	_objc_msgSend
    movq	%rax, -8(%rbp)

If you went and poked about in the x86_64 ABI specification (either of those links will work), you would recognize the above as code that sets up a call to a function — to _objc_msgSend() — and then stores the return value a local variable.

That is, objc_msgSend() and, by inference of being tail call optimized and not screwing with registers or stack layout, the method implementations themselves are just standard C functions that follow standard C ABI conventions.

Or, to put it another way, any method can be rewritten as an equivalent C function. The equivalent C function for the doSomething: method above could be declared as:

id doSomething(id self, SEL _cmd, NSUInteger index) { ... }

And, sure enough, if we call that function, we get functionally equivalent assembly code generated:

    b = doSomething(a, @selector(doSomething:), 0x2b); // line 16
    .loc 1 16 0
    movq	L_OBJC_SELECTOR_REFERENCES_0(%rip), %rsi
    movq	-16(%rbp), %rdi
    movl	$43, %edx
    call	_doSomething
    movq	%rax, -8(%rbp)

In particular, on the x86_64 architecture for this particular simple function or method call, the arguments (again, this is only for a simple set of non-struct arguments and return values) will fall into a series of registers in the CPU across the call boundary.

Specifically, the self parameter will be found in %rdi, _cmd in %rsi, and the first declared argument in %edx, followed by %ecx, %r8d, %r9d, and then arguments are pushed onto the stack. Once again, this assumes that the arguments are all of simple type — integers, ids, pointers, etc… — and the rules change with structures and other non-trivial types. Actually, this is another good reason for objc_msgSend to not mess with the stack and registers as the ABI rules are both rather complex and there simply isn’t enough information available at runtime to go off changing argumentation across the messaging boundary (much less do so efficiently)!

We now have enough information to know what state the CPU is in when the call to objc_msgSend() is made. Next up will be the most typical method dispatch.

The motivation behind these posts is entirely selfish. I find the best way for me to learn something is to know it well enough to be able to explain any detail to a room full of folks in full-blown student mode.

Table of Contents

1. objc_msgSend() Tour Part 1: The Road Map
2. objc_msgSend() Tour Part 2: Setting the Stage
3. objc_msgSend() Tour Part 3: The Fast Path
4. objc_msgSend() Tour Part 4: Method Lookup & Some Odds and Ends

For a variety of reasons, I oft find myself staring at streams of x86_64 instructions. This is often the stream of instructions that sit at the very core of Objective-C and dispatch each and every method call. That is, objc_msgSend().

Well, technically, a handful of different versions of objc_msgSend(), each written to handle the calling conventions required to deal with various return types under the x86_64 ABI (Application Binary Interface). Oh, and the vtable dispatch stuff (different post).

Obviously, objc_msgSend() is called 10s of millions of times simply booting the system and launching some apps. Thus, every cycle counts and, no surprise, objc_msgSend() is written in hand tuned assembly. Of all of the other performance optimizations and implementation details in this code, there are three that I find particularly notable.

Don’t Mess With Registers (unless absolutely necessary)
Tail Call Optimized
Don’t Mess with the Argument List

These are really all three part of the same thing (i.e. some arguments are in registers, for example). objc_msgSend() is designed to dynamically determine the implementation of a method — the function pointer that is the IMP tied to the selector on the targeted instance — without changing any of the caller/callee state. This enables a tail-call optimization that allows objc_msgSend() to jump [JMP] directly to the implementation of a method.

This is also the reason why you don’t see objc_msgSend() in backtraces save for when a crash occurs in objc_msgSend(). Given that there were several 10s of millions of invocations of objc_msgSend() prior to the one that crashed, you can pretty much always assume that the crash is because of a bad pointer being passed to objc_msgSend() and not due to a bug in objc_msgSend() itself. Of course, if you find yourself crashing in objc_msgSend(), go read and then re-read this.

This relative handful of instructions — 76 in the disassembly below (taken on Snow Leopard 10.6.2 — objc-437.1), most of which are not executed in a typical method dispatch — does an awful lot of stuff upon each invocation.

Namely:

1. Check for ignored selectors (GC) and short-circuit.
2. Check for nil target.
3.     If nil & nil receiver handler configured, jump to handler
4.     If nil & no handler (default), cleanup and return.
5. Find the IMP on the class of the target and jump to it

1. Search the class’s method cache for the method IMP
2.     If found, jump to it.
3. Not found: lookup the method IMP in the class itself
4.  
       If found, jump to it.
5. If not found, jump to forwarding mechanism.

The next part will set the stage for diving into the actual objc_msgSend() stream.

Ultimately, the whole point of resurrecting my old screensaver code was to finally port DPhyllotaxis to Snow Leopard.

Beyond being, perhaps, the most over-engineered screen saver ever for what ultimately draws colored dots, I wrote this as a sort of virtual flower for my then-girlfriend, now-wife-of-more-than-a-decade, Christine.

The underlying algorithm on this one is based entirely on phyllotaxis and the phyllotactic pattern of growth seen across so much of the plant world. The most well known example being the layout of seeds in a sunflower and that particular form of phyllotaxis is exactly what this screensaver mimics.

The color calculation in this particular screen saver is, frankly, goofy. Every floret — every dot — is actually rendered. The brightness is determined by calculating a color once, grabbing the red component and then calculating the color again using a slightly different algorithm and using the previous red value as the new brightness. Rather silly, but the results are pleasant enough.

When I originally wrote this in 1994-ish, it used Display PostScript to do all the drawing. Specifically:

/* this should not be done here */
PSarc(cp.x, cp.y, 15. + (11. * pp.r), 0, 360);
PSgsave();
PSfill();
PSgrestore();
NXSetColor(NX_COLORBLACK);
PSstroke();

I have no idea why, 15 years ago, I thought it important to note that “this should not be done here”. None. So, in the ported code, the comment is gone.

CGFloat floretDiameter = 10. + (11. * pp.r);
CGFloat floretRadius = floretDiameter / 2.;
NSRect floretRect =
    NSMakeRect(cp.x - floretRadius,
    cp.y - floretRadius,
    floretDiameter, floretDiameter);
NSBezierPath *floretPath = [NSBezierPath
    bezierPathWithOvalInRect: floretRect];

[floretPath fill];

[[NSColor blackColor] set];
[floretPath stroke];

There are, of course, many ways to make the above a ton faster. Save for reducing power usage by going a more efficient route, it just doesn’t matter for this particular use case as I already had to slow down the animation rate considerably.

Seems there has been a bit of performance jump between the 25MHZ 68040 this was originally written on and the 2GHZ Core 2 Duo machine I used for the porting work.

Code is in the same repository as the other screen savers. I also tossed a pre-built binary on the server. Only tested on 64-bit Snow Leopard, but it might should also work on 10.5 ppc/i386.

In Objective-C, a class can implement +initialize. This method will be invoked the first time the class is touched, prior to any other methods (other than +load).

The documentation says:

The runtime sends initialize to each class in a program exactly one time just before the class, or any class that inherits from it, is sent its first message from within the program.

Which is exactly true. But your +initialize methods can still be executed more than once!

Specifically, if a subclass does not implement +initialize but its superclass does, then that superclass’s +initialize will be invoked once per non-implementing subclass and once for itself.

An example (Foundation Tool, Garbage Collected):

@interface Abstract: NSObject
@end
@implementation Abstract
+ (void) initialize
{
    NSLog(@"Initializing %@", self);
}

+ (void) load
{
    NSLog(@"Loading");
}
@end

@interface Sub : Abstract
@end
@implementation Sub
@end

int main (int argc, const char * argv[]) {
    [Sub class];
    return 0;
}

This will output:

ArgyBargy[3720:903] Loading
ArgyBargy[3720:903] Initializing Abstract
ArgyBargy[3720:903] Initializing Sub

Which is why most +initialize methods are implemented as:

@implementation MyClass
+ (void) initialize
{
    if (self == [MyClass class]) {
        // ... do +init stuff here ...
    }
}
...
@end

Now, categories can seriously screw things up (as usual). Namely, if you implement +initialize in a category, it will override the classes +initialize. However, a category provided +load will not; both the category’s and the class’s +load methods will be invoked.

If you were to add the following category to the Sub/Abstract/NSObject example above:

@interface Abstract(Cat)
@end
@implementation Abstract(Cat)
+ (void) load
{
    NSLog(@"Category +load");
}
+ (void) initialize
{
    NSLog(@"Category +initialize %@", self);
}
@end

The program will spew:

ArgyBargy[3919:903] Loading
ArgyBargy[3919:903] Category +load
ArgyBargy[3919:903] Category +initialize Abstract
ArgyBargy[3919:903] Category +initialize Sub

Keep in mind, as well, that the runtime sends +initialize “in a thread-safe manner”. That implies that there is a lock involved somewhere within which then also implies that you better not block on a lock in your +initialize because whoever is supposed to unlock the lock might end up blocking on +initializes lock.

Or, to put it more bluntly, do not do any heavy lifting in +initialize. Keep it super simple & fast.

For me, +initialize is to be used only as a method of last resort. Well, 2nd to last. Last resort is a constructor attributed function (or +load).In the comments, James says:

+initialize is a great place to do heavy lifting. … Your objection about not performing any locks in +initialize is non-sensical. The runtime won’t allow any other other threads to send a message to the class until the +initialize message returns.

That claim is wrong.

While it is a great place to, say, initialize very simple global state– string constants, the date, etc… — +initialize is a horrible place to do any kind of heavy lifting for several reasons.

Most critically, it is impossible to know what order the classes will be +initialize‘d and said order will change across system configurations and, even, software updates. This leads to a need to do some kind of exclusion locking or something such that the initialization code paths are only followed once. But, more often than not, “heavy lifting” in the +initialize will trigger other classes to be initialized.

End result? A mess of interleaved locks whose complexity quickly grows out of control.

Here is a dead simple example of a +initialize deadlock:

#import <Foundation/Foundation.h>

@interface Bleep : NSObject
@end
@interface Blorp : NSObject
@end

static NSLock *initializationLock;

@implementation Bleep
+ (void) initialize
{
    NSLog(@"%s", class_getName(self));
    [initializationLock lock];
    NSLog(@"%@", [Blorp new]);
    [initializationLock unlock];
}
@end

@implementation Blorp
+ (void) initialize
{
    NSLog(@"%s", class_getName(self));
    [initializationLock lock];
    NSLog(@"%@", [Bleep new]);
    [initializationLock unlock];
}
@end

int main (int argc, const char * argv[]) {
    initializationLock = [NSLock new];
    [Blorp new];
    return 0;
}

Conveniently, the runtime detects the deadlock for us:

209 BleepBlorb[33953:903] Blorp
213 BleepBlorb[33953:903] Bleep
214 BleepBlorb[33953:903] *** -[NSLock lock]: deadlock (<NSLock: 0x20000f340> '(null)')
214 BleepBlorb[33953:903] *** Break on _NSLockError() to debug.

And the backtrace at the point of deadlock is interesting beyond the obvious failure:

#0  semaphore_wait_signal_trap ()
#1  pthread_mutex_lock ()
#2  -[NSLock lock] ()
#3  +[Bleep initialize] (self=0x100001120, _cmd=0x7fff8790a148) at /tmp/BleepBlorb/BleepBlorb.m:15
#4  _class_initialize ()
#5  prepareForMethodLookup ()
#6  lookUpMethod ()
#7  objc_msgSend ()
#8  +[Blorp initialize] (self=0x1000010d0, _cmd=0x7fff8790a148) at /tmp/BleepBlorb/BleepBlorb.m:26
#9  _class_initialize ()
#10 prepareForMethodLookup ()
#11 lookUpMethod ()
#12 objc_msgSend ()
#13 main (argc=1, argv=0x7fff5fbff7e0) at /tmp/BleepBlorb/BleepBlorb.m:37

In particular, it shows that the runtime, in and of itself, can trigger class initialization as a part of method lookup, thus implying even less control over initialization order than one might assume.

Now, of course, this is a contrived example. However, this particular pattern of dysfunctionality is quite easy to grow into as the complexity of initialization increases. Worse, it can be equally as easy to end up in a situation where the deadlock only occurs some of the time; only on some app launches on some subset of customers machines.

This isn’t just conjecture. I have intermittently spent quite a few hours at a time debugging this exact kind of deadlock across various applications (that shall remain nameless– popular apps, they were).

For the record, +load is an even worse time to do heavy lifting. The runtime environment is in an extremely non-deterministic state at that time.

This post is focused solely on the core syntax of Blocks; declaring a block and calling a block.

Blocks are closures for C.

That is, a block is an anonymous inline collection of code that (Note: lexical scope means function or method or {}-surrounded collection of statements:

• has a typed argument list just like a function
• has an inferred or declared return type
• can capture state from the lexical scope within which it is defined
• can optionally modify the state of the lexical scope
• can share the potential for modification with other blocks defined within the same lexical scope
• can continue to share and modify state defined within the lexical scope [the stack frame] after the lexical scope [the stack frame] has been destroyed

Blocks is available in GCC and Clang as shipped with the Snow Leopard Xcode developer tools. The Blocks runtime is open source and can be found within LLVM’s compiler-rt subproject repository. Blocks have also been presented to the C standards working group as N1370: Apple’s Extensions to C (which also includes Garbage Collection).

As Objective-C and C++ are both derived from C, Blocks are designed to work fine with all three languages. Thus, the syntax reflects this goal.

A block is introduced using the ^ — the caret — character. The ^ was chosen as it had no unary form (and C++ couldn’t operator overload it).

For the purposes of an excruciatingly simple example, how about a block that multiplies two numbers?

Declaring a variable that could refer to such a Block would be done with something akin to a function pointer:

    int (^multiplyIt1)(int, int);

Of course, if one were to have a slew of different blocks that could multiply two ints in a slew of novel and innovative ways, the type of the Block could be captured in a typedef:

    typedef int (^MultiplyItBlockType)(int, int);
    ....
    MultiplyItBlockType multiplyIt2;

Capturing a bit of code — a unit of work — in a block and assigning it to one of the above variables is as follows:

    multiplyIt1 = ^(int x, int y) { return x * y; };

Since a block typed variable is simply a reference to a chunk of code — a unit of work — then simple assignments work, too:

    multiplyIt2 = multiplyIt1;

To execute a Block, it is called just like a function:

    int result = multiplyIt1(7,6);
    printf("multiplyIt1(7,6) = %d\n", result);

Which spits out multiplyIt1(7,6) = 42.

Just like function pointer syntax, it is possible to declare types that are rather more complex. Blocks that take blocks as arguments or return blocks? Sure. Works fine. Functions that return arrays of blocks that return arrays of function pointers? Yup. Compiler will correctly eat that too.

Whatever C perversion you can imagine, Blocks should play nicely. There are some rough edges with certain C++ perversions, though.

Embracing typedefs can reduce the insanity factor.

Objective-C is a simple set of extensions to C. Whatever C provides, Objective-C does to. And this includes blocks.

Defining a method that takes a block as an argument works just like declaring a method that takes a function pointer as an argument:

- (void)enumerateObjectsUsingBlock:(void (^)(id obj, NSUInteger idx, BOOL *stop))block;

The above is one of the many new bits of API in Snow Leopard that use Blocks.

A style tip; when declaring a function or method that takes a Block as an argument, always try to limit it to just one Block argument and always make said Block argument the last argument. It makes the code easier to read and write at the call site:

    NSArray *frameworks = [NSBundle allFrameworks];
    [frameworks enumerateObjectsUsingBlock:^(id aFramework, NSUInteger i, BOOL *stop) {
        NSLog(@"Framework path: %@", [aFramework bundlePath]);
    }];

Just like all other C types, Blocks can be used as instance variables and/or properties.

And there you have Basic Blocks. Next up? The innards of Blocks…

I recently picked up an ExpressCard/34 SD reader along with a Transcend 16GB SDHC card. The reader was to ease the transfer of photos from a digital camera and the high-cap SDHC card ensures I can take plenty of photos without shuffling about cards.

With the recent announcement of SD-slot-ness MacBook Pros (drool) that can boot from the SD slot, it made me wonder if a previous generation MacBook Pro could do so, too.

And it can! Which isn’t totally surprising. SD ExpressCard readers effectively act like USB drives and most (all?? I don’t know) Intel macs can boot from USB devices.

On the click through is instructions for formatting an SD car correctly and slapping down a bootable image.

Given the relatively low prices of SD cards, I’m making a habit of carrying around a “rescue card”. Tiny enough to not be noticeable, can be reformatted to use as photo-space trivially, one hell of a lot of tougher than optical media, and will prove to be indispensable if I ever need it.



Out of the box, an SD card will be formatted with an MS-DOS (FAT) filesystem.

Useless (except for in digital cameras).

But it isn’t enough to just reformat it to be an HFS+ Journaled filesystem. You also need to change the partitioning table.

To do so:

• Launch Disk Utility
• Insert the SD card
• Select the volume (labeled 16.06 GB Generic STORAGE DEVICE Media in my case)
• Select the Partition tab
• Select 1 Partition from the Volume Scheme. Even if there is only one partition, selecting 1 Partition will enable the all critical Options… button at the bottom
• Click Options… and select GUID Partition Table.
• Make sure the partition will be formatted as Mac OS Extended (Journaled)
• Click Apply

You now have an SDHC card ready to be made bootable. From here, you could install Mac OS X to the card, install something like a DiskWarrior bootable image to the card, copy an already bootable partition to the card or blast down a bootable DMG to the card.

Disk Utility makes it trivial to clone whole volumes from one partition to another. If you do so, make sure and check erase destination as that will ensure that Disk Utility uses a block based copy and, thus, is about a zillion and twenty times faster.

If you have a bootable disk image around, you can easily use Disk Utility to restore the image to the partition or you can use the command line:

sudo asr -source /path/to/bootable.dmg -target /Volumes/SDCard -erase -noverify -noprompt

Then, reboot your mac and hold down the option key. The newly created boot partition should show up.

It is fast enough to boot for installation, recovery, or intermittent use.