Widgets Home Grown in Austin

15 December 2007 @ 1pm

Development, Mac

Collecting Leopard’s Garbage

Memory management is a delicate yet required skill of many who program. Those who program in C know the fine detail of managing each and every byte while those who have broadened out to Objective-C have enjoyed a slightly more relaxed thought process. Java developers on the other hand have lived in a virtual la la land of near memory management nirvana. With Leopard, Mac developers jump to within a few steps of nirvana and land in a really sweet spot.

Leopard’s Cocoa garbage collection manages application memory for the developer freeing them from most tedious memory management issues. With garbage collection each objects retain count no longer need to be explicitly maintained. For example, prior to garbage collection the following method would create a memory leak:

- (NSString *) moodForUserWith:(NSString *)userName
    NSMutableString *mood = [[NSMutableString alloc] init];
    [mood appendString:userName];

    if(friday) {
        [mood appendString:@" is Happy!"];
    } else {
        [mood appendString:@" is Sad!"];

    return mood;

Now with garbage collection this method does not leak memory even though the retain count of the string object has been ignored by the developer.

Using the Garbage Collector

The garbage collector runs automatically by finding an opportune time within the event cycle for collection assuming that a certain memory load threshold has been exceeded. Starting at the applications root objects collection involves recursively searching through the object graph by following all strong object references. Any objects not connected to the root objects via the graph are designated as ‘garbage’. At the end of the collection all objects designated as garbage have their finalize method run and memory freed.

It must be noted that in Leopard garbage collection is optional and disabled by default. In order to enable it a compiler flag must be set in each XCode projects build settings.

garbage collector build setting


The ‘Unsupported’ setting designates that the garbage collector will not be engaged and standard retain/release style memory management will be used. Likewise, the ‘Required’ setting designates that the garbage collector will be used. The ‘Supported’ setting tells the compiler that retain/release logic is present but that the garbage collector can be run if possible. Currently, Apple recommends that applications not be designed to support this dual mode operation except in cases in which it makes sense such as for frameworks that may be used by client environments which run in either of the collected or managed memory modes.

A limitation of this flexibility is that all libraries and frameworks used by an application must also support garbage collection. This can be a major roadblock for any application wishing to include older libraries in order to provide supporting functionality. Over time this limitation may diminish as libraries and frameworks are updated but it will likely take some time before this happens.

1 Comment

Posted by
18 August 2008 @ 4am

Your blog is interesting!

Keep up the good work!

Leave a Comment