TweetFollow Us on Twitter

Developer to Developer: Thanks for the Memory-Part 2

Volume Number: 26
Issue Number: 11
Column Tag: Developer to Developer

Developer to Developer: Thanks for the Memory-Part 2

A look at how memory is managed in Objective-C

by Boisy G. Pitre

Introduction

If you followed last month's Developer to Developer column, you'll recall that we went through an introduction to memory management in Objective-C and Cocoa applications. That article was well suited to those who were new to Mac and iOS development, and touched on a number of concepts that are unique to Apple's development environment. For comparison, we also looked at how memory management is done in C and C++. Also, we touched on how Java programmers are greatly insulated from any memory considerations due to garbage collection.

This month we'll build upon the previous article and wade a little deeper into the waters of Objective-C memory management. We will start out by looking at a special subclass of NSObject that we can use to see just how our objects behave when they are created, retained, released and deallocated. We'll also take a look at the NSAutoreleasePool class, which gives us a convenient way to defer the release of an object and the return of its memory to the system. Finally, we will take Instruments, Apple's robust developer tool, for a spin.

Seeing Is believing

As we discussed last month, memory management in Objective-C consists of requesting an ownership interest in an object by retaining it, and relinquishing that ownership interest by releasing it. These operations can occur numerous times within an application for the same object. Balancing them is key to insuring that the memory that an object occupies is not left to leak while the application runs. Conversely, we must guard against the memory being returned to the system too soon, which could result in a crash, depending upon how that object is accessed later.

How convenient would it be to actually visualize this process happening in real-time? Well, it can be done, and quite readily, by subclassing NSObject and creating a new base class which overrides the retain and release methods, among others. And that's exactly what we will do. I highly recommend that you follow along by downloading the code for this month's article from the MacTech FTP source archive at ftp://ftp.mactech.com and launching the project file in Xcode. The application is made up of simple, contrived examples that are useful in illustrating the mechanics of object allocation and deallocation.

When determining what methods to override, we can consult two resources: the NSObject Class Reference (available in the Xcode's Developer Documentation, accessible from the Xcode Help menu) or the NSObject.h header file itself. Let's take the header file route and take a peek at NSObject.h directly. To do this easily from within Xcode, go to the File > Open Quicky... menu option, then type NSObject.h. It should appear in the drop down box; select it and it will be displayed in an Xcode text editor window.


Figure 1 - Opening the NSObject.h header file

The header file is composed of several sections: basic protocols, the base class, discardable content and object allocation/deallocation. For this article, we're going to focus on methods in the basic protocols and base class sections of the header file (starting at lines 11 and 63 respectively of the header file in the 10.6 SDK). Of the methods declared in the basic protocols section, let's override the following:

- (id)retain;
- (oneway void)release;
- (id)autorelease;

Similarly, let's override the following methods declared in the base class section:

- (id)init;
- (void)dealloc;

Lastly, for informational purposes, we'll override this method:

+ (id)allocWithZone:(NSZone *)zone;

There may be some questions as to the choice of methods to override. Remember, we are trying to capture the memory management operations in a way that allows us to visually confirm them as they happen. Most of the above methods are vectors for the retain count changing. By overriding these methods with methods in a subclass that (a) calls the same method in NSObject, and (b) logs the call itself and the retain count, we can see Objective-C memory management in action.

As mentioned earlier, overriding the methods requires subclassing NSObject. We'll create a new class just for the Developer to Developer column, DDObject, as a direct descendant of NSObject, so any class who inherits from DDObject will automatically benefit from the methods that we will embellish. Let's start out by looking at the code for the retain and release methods:

- (id)retain;
{
   id result = [super retain];
   NSLog(@"[%@ retain] (retainCount = %d)", [self className], [self retainCount]);
   return result;
}
- (oneway void)release;
{
   NSLog(@"[%@ release] (retainCount = %d)", [self className], [self retainCount] - 1) withLevel:TBLogLevelInfo];
   [super release];
}

Both methods mimic the return values of their original definitions in NSObject.h and use the NSLog() function to show the name of the class and the retain count. The retain method returns the retain count after the superclass' retain method is called, while the release method shows the retain count first. This ordering insures that we see the true retain count value at the appropriate place and time.

The init and dealloc methods are also points where observing the retain count can be instructive, so we'll extend these as well:

- (id)init;
{
   if (self = [super init])
   {
      NSLog(@"[%@ init] (retainCount = %d)", [self className], [self retainCount]);
   }
   
   return self;
}
- (void)dealloc;
{
   NSLog(@"[%@ dealloc]", [self className]);
   [super dealloc];
}

Even though we explicitly call retainCount in the init method, it will always print a retain count of 1. The dealloc method is called only when the retain count goes to 0; since a release call precedes this, we'll forego logging the retain count, and simply log that we are deallocating the object's memory here.

Finally, we'll override the allocWithZone: method, which will clue us in when an allocation is taking place (as we'll see shortly, the alloc method actually calls allocWithZone: with a zone of 0):

+ (id)allocWithZone:(NSZone *)zone;
{
   NSLog(@"[%@ allocWithZone:%d]", [self className], zone);
   return [super allocWithZone:zone];
}

Now that the pieces are in place, let's take a look at memexplore.m. This file contains the main() function, several test functions, and the interface and implementation for the MemObject class. This class extends the DDObject class which we just reviewed, so we would expect to see some interesting output when we run the test. Let's go ahead and do that now. First, build the memexplore target (Build > Build). Next, ensure that the Debugger Console is in focus so that the logging results can be seen (Run > Console). Finally, run the application (Run > Run). A menu appears where you can type the number of the test to perform. Let's run the allocRunRelease test by typing 1 then the return key.


Figure 2 – Output of the allocRunRelease test

The output of this test clearly shows the steps in which our MemObject comes to life, runs, then is finally released. As expected, the init method shows that the retain count is 1. The run method is then called, and finally the release method. Recall that this method decrements the retain count by 1; this is confirmed by the retain count falling to 0, and the dealloc method being implicitly called after that. Just to be convincing that the retain count can go higher, the allocRunReleaseMultiple test performs a retain after allocating and initializing the MemObject object, as well as an extra release. The net effect is the same: the object's dealloc method is called when the retain count falls to 0. Go ahead and run this test as well.


Figure 3 - Output of the allocRunReleaseMultiple test

One might conclude that the "hands-on" memory management aspect of Objective-C is a bit laborious. After all, we not only explicitly allocate and initialize an object, we must also take care to properly release it. Not releasing an object after we are done with it denies the use of that memory elsewhere; if an application doesn't release an object properly, it will stay around until the application quits, which could be a short time or a long time. Even though current systems contain gigabytes of memory and can accommodate a bit of sloppy memory management, it is considered bad programming practice to tolerate memory leaks. On mobile devices such as the iPhone and iPad where resources are limited, it is even more critical to wipe out these types of memory leaks.

Swimming In The NSAutoreleasePool

As we discussed, balancing retains with releases insures that we avoid memory leaks or crashes. It is a disciplined approach, and forces us to think about the lifetimes of our objects. However, Cocoa gives us a bit of a reprieve from the tedium of retain count management. We can make things a little easier for ourselves by conveniently deferring the return of an object's memory to the system using a special type of class provided by the Cocoa framework: NSAutoreleasePool.

An autorelease pool acts as a sort of dumping site for objects; upon receiving an object, the pool dutifully records a reference to the memory location of objects for later releasing. Any object can be relegated to the autorelease pool by having the autorelease message sent to it:

   SomeObject *s = [[[SomeObject alloc] init] autorelease];

The autorelease message allows us to pass complete responsibility of releasing the object to the NSAutoreleasePool. By doing this, we essentially wash our hands of further worry about the lifetime of the object and the memory that it is taking up. In the above code fragment, the object s receives the autorelease message after the alloc and init messages; subsequent to that, we can use the object as needed but should not send the release message to the object. That will be performed by the autorelease pool at a later time.

Exactly where autorelease pools are created depends upon the context in which you are writing your program. In Cocoa applications, an autorelease pool is created for you automatically, so you don't have to concern yourself with its creation. However, if you are using threads, you will need to create and manage your own autorelease pool for that thread. And in the case of a command line based program such as memexplore, it is necessary to create an autorelease pool as well.

Autorelease pools can be created many times, with the most recent pool being the one that receives any objects that receive the autorelease message. In essence, autorelease pools are stacked as they are created. When the topmost autorelease pool is destroyed, the next autorelease pool will receive autoreleased objects. Destroying an autorelease pool is similar to destroying any object: sending a release message to the pool will cause it to in turn send release messages to all objects that it holds, and finally the pool itself is deallocated. A slight twist on this is that since the release of Objective-C 2.0 and garbage collection, the drain message is the desired message to send to an autorelease pool instead. This message performs the same function as the release message, but does additional work in a garbage collected environment. For our code, we'll use the drain message when releasing our pools.

Can we peek into an autorelease pool? We certainly can, thanks to the NSDebug.h header file's NSAutoreleasePoolDebugging category. The showPool message, when sent to an autorelease pool object, will display the contents of all pools in the pool stack to the standard error path. We use this debugging method in several of our test programs to illustrate what the pool looks like just before it is drained. To illustrate this, run test 1 (allocRunRelease) then test 5 (allocRunReleaseWithPoolOverRetain). The final output will look like this:

==== top of stack ================
  0x100110b00 (NSCFString)
  0x100110ae0 (NSCFString)
  0x100110920 (MemObject)
  0x100110a70 (NSCFString)
  0x100110a50 (NSCFString)
  0x100110a30 (NSCFString)
==== top of pool, 6 objects ================
  0x1001109b0 (NSCFString)
  0x1001109e0 (NSCFString)
  0x100110990 (NSCFString)
  0x1001108b0 (NSCFString)
  0x100110070 (NSCFString)
==== top of pool, 5 objects ================

The pool appearing on the very top of the stack was created in the allocRunReleaseWithPoolOverRetain() function and has 6 objects, including a MemObject which we overretained and is just leaking. The next pool was created in the main() function has 5 objects. You may be wondering what is going on with all of the NSCFString objects in the autorelease pool. Those are the various string literals which appear in the NSLog() functions that have been executed during the program's run. As objects themselves, these strings require memory management, and they are automatically added to the autorelease pool when initialized.

Pool Hazards

As convenient as autorelease pools are, they must be used with care. The same problems that we discussed last month (overretaining/underreleasing or overreleasing/

underretaining) can still lead to memory leaks or crashes. A common mistake that many beginning programmers make is to send a release message to an object after it has been sent an autorelease message. The net effect of that transgression is that the object will end up being overreleased, and a crash is likely. The allocRunReleaseWithPoolOverRelease test illustrates this poignantly.

   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   NSLog(@"- allocRunReleaseWithPoolOverRelease -");
   MemObject *s1 = [[[MemObject alloc] init] autorelease];
   [s1 run];
   [s1 release];
   NSLog(@"----------------");
   [NSAutoreleasePool showPools];
   [pool drain];

Note that the autorelease message is sent to the s1 object upon creation, then a release message follows. It is at that point which the object's retain count goes to 0 and its dealloc method is called. Since its reference is also in the autorelease pool, the simple act of sending the showPools method is enough to trigger an access exception and crash the program.

Another interesting hazard is having no autorelease pool at all. Without an autorelease pool, objects sent an autorelease message (including NSCFString string literals that we saw above) have nowhere to go, and just leak all over the place. If you ever see a message like this coming from your application:

*** __NSAutoreleaseNoPool(): Object 0x100110770 of class NSCFString autoreleased with no pool in place - just leaking

then you know that somewhere, an autorelease pool is needed but doesn't exist. This most commonly happens when using threads and failing to create an autorelease pool. As a rule, your thread's entry point method should create an autorelease pool at the beginning, then drain the pool at the end.

Inspecting Memory Leaks With Instruments

Apple's Instruments is part of the Xcode development suite, and is a powerful tool for strengthening and bulletproofing your applications in a number of areas. When it comes to memory usage and management, it is particularly useful, and has handy two templates that are a must: Allocations and Leaks. The former template shows you exactly what objects and how many are being allocated by your application. The latter gives you insight into where your application may be leaking memory.

Typically, Instruments can be invoked from within Xcode's Run menu. Given that our application is a windowless application whose input and output appear on the console, we'll start Instruments from the Finder and then attach to the running process.

Before starting Instruments, go ahead and run the memexplore program from within Xcode. Now let's start Instruments by navigating to the /Developer/Applications folder in the Finder and double-click the Instruments icon. You will see a window with a drop-down sheet asking for the template to use. Select the Leaks template and click the Choose button.


Figure 4 - Selecting the Leaks template from Instruments

With the template chosen, you will see the main Instruments window with both the Allocations and Leaks templates shown. Since our application is running, we can attach to it from the Choose Target button and selecting the Attach to Process menu item, then navigate the list of running processes until we find memexplore. After memexplore has been selected, click the Record button in the toolbar. This starts the process of recording all object allocations as well as the leak detection procedure.


Figure 5 - Selecting the memexplore process from Instruments

With Instruments recording the memexplore application, switch to the Xcode console and select test 5 (allocRunReleasePoolWithPoolOverRetain). This test purposely performs an extra retain to the object so that it will leak. After the test is run, switch back to Instruments and click on the Leaks template header on the left side of the window. Within a a short time, the leaked object name should appear, along with the address and size. Clicking the third button of the view group in the toolbar will reveal the extended detail including the stack trace where the leak occurred. As we can see in the stack trace, the DDObject's allocWithZone: method is where the leak originated.


Figure 6 - Instruments showing the memory leak in memexplore

Summary

As we have seen, mismanaging an object's lifetime through its retain count can have ramifications for the health of your applications. Autorelease pools give us some convenience but even so, we must still be vigilant when balancing our retains and releases. Crashes are often caused by objects being released prematurely, and leaks are the result of retaining an object beyond its lifetime. It's times like these when Apple's Instruments can pinpoint the exact spot where the leak occurred, and we can take corrective action. For those of you who have started delving into Objective-C, these articles and the accompanying code should give you a basis for understanding memory management as well as a springboard to further experimentation.

Bibliography and References

Apple. Instruments User Guide. http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/InstrumentsUserGuide.pdf

CocoaDev. DebuggingAutorelease.

http://www.cocoadev.com/index.pl?DebuggingAutorelease


Boisy G. Pitre lives in Southwest Louisiana and is the lead developer at Tee-Boy where he also consults on Mac and iOS projects with a variety of clients. He holds a Master of Science in Computer Science from the University of Louisiana at Lafayette. Besides Mac programming, his hobbies and interests include retro-computing, ham radio, vending machine and arcade game restoration, and playing Cajun music. You can reach him at boisy@tee-boy.com.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

OmniGraffle Pro 7.19.3 - Create diagrams...
OmniGraffle Pro helps you draw beautiful diagrams, family trees, flow charts, org charts, layouts, and (mathematically speaking) any other directed or non-directed graphs. We've had people use... Read more
OmniGraffle 7.19.3 - Create diagrams, fl...
OmniGraffle helps you draw beautiful diagrams, family trees, flow charts, org charts, layouts, and (mathematically speaking) any other directed or non-directed graphs. We've had people use Graffle to... Read more
Hopper Disassembler 5.3.3- - Binary disa...
Hopper Disassembler is a binary disassembler, decompiler, and debugger for 32- and 64-bit executables. It will let you disassemble any binary you want, and provide you all the information about its... Read more
calibre 5.35.0 - Complete e-book library...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital librarian... Read more
Sound Studio 4.10.0 - Robust audio recor...
Sound Studio lets you easily record and professionally edit audio on your Mac. Easily rip vinyls and digitize cassette tapes, or record lectures and voice memos. Prepare for live shows with live... Read more
Sparkle Pro 4.0 - Visual website creator...
Sparkle Pro will change your mind if you thought building websites wasn't for you. Sparkle is the intuitive site builder that lets you create sites for your online portfolio, team or band pages, or... Read more
Dropbox 140.4.1951 - Cloud backup and sy...
Dropbox for Mac is a file hosting service that provides cloud storage, file synchronization, personal cloud, and client software. It is a modern workspace that allows you to get to all of your files... Read more
FotoMagico 6.0.5 - Powerful slideshow cr...
FotoMagico lets you create professional slideshows from your photos and music with just a few, simple mouse clicks. It sports a very clean and intuitive yet powerful user interface. High image... Read more
Remotix 6.4.2 - Access all your computer...
Remotix is a fast and powerful application to easily access multiple Macs (and PCs) from your own Mac. Features: Complete Apple Screen Sharing support - including Mac OS X login, clipboard... Read more
Microsoft Office 365, 2019 16.57 - Popul...
Microsoft Office 365. The essentials to get it all done. Unmistakably Office, designed for Mac Get started quickly with new, modern versions of Word, Excel, PowerPoint, Outlook and OneNote-... Read more

Latest Forum Discussions

See All

A House Full of Covid – The TouchArcade...
It’s been a rough week as both of our young children tested positive for Covid, and since recording this early on Friday my wife has tested positive now too. Thankfully the kids seemed to recover fairly quickly and are mostly back to normal, and I... | Read more »
TouchArcade Game of the Week: ‘Krispee S...
Krispee Street is a new hidden object game from Frosty Pop that is based on their popular and almost painfully sweet webcomic Krispee. This is one of the latest titles to be added to the Netflix Games catalog, which means you’ll need to log into... | Read more »
SwitchArcade Round-Up: ‘Escape Lala’, ‘B...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for January 21st, 2022. In today’s article, we’ve got a lot of new releases. A lot. There were eight on the schedule when I went to bed last night. There were twenty-four when I woke up... | Read more »
Beta Testers Needed for Huge Version 2.0...
Ya’ll remember Dungeon Raid, right? The phenomenal matching RPG hybrid that launched on mobile more than a decade ago, but was more or less abandoned by its developer only to die a slow death on the App Store before the 32-bit Appocalypse finally... | Read more »
‘Ark Legends’ Gives Players a Chance to...
It’s Airpods and Amazon gift cards galore as Melting Games opens pre-registration for Ark Legends. The upcoming mobile RPG is giving away tons of in-game goodies such as gold, energy, iron core, hero summon chest and rare iron core to players who... | Read more »
‘Nickelodeon Extreme Tennis’ Out Now on...
Nickelodeon Extreme Tennis () from Old Skull Games and Nickelodeon is this week’s new Apple Arcade release. Nickelodeon Extreme Tennis features characters from old and new Nickelodeon shows including SpongeBob, TMNT, and many more. The tennis game... | Read more »
SwitchArcade Round-Up: ‘RPGolf Legends’,...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for January 20th, 2022. In today’s article, we’ve got a massive amount of new releases to check out. We’ve got summaries of all of them, from heaven to hell. We also have the lists of... | Read more »
‘Zed Blade ACA NEOGEO’ Review – Well, It...
SNK’s NEOGEO platform played host to a great many classics, both famous and under-the-radar. The Metal Slug games. The King of Fighters series. Magician Lord. Shock Troopers. Sengoku 3. NEO Turf Masters. Fatal Fury. Samurai Shodown. Twinkle Star... | Read more »
‘Inua – A Story in Ice and Time’ is a Un...
One thing I know about ARTE from their output on mobile over the years is that they love collaborating with really interesting and unique studios to put out really interesting and unique gaming experiences. This is true yet again with the latest... | Read more »
Out Now: ‘Angry Birds Journey’, ‘RPG Dic...
Each and every day new mobile games are hitting the App Store, and so each week we put together a big old list of all the best new releases of the past seven days. Back in the day the App Store would showcase the same games for a week, and then... | Read more »

Price Scanner via MacPrices.net

Amazon lowers prices on select 13″ M1 MacBook...
Amazon has select Apple 13″ M1 MacBook Airs on sale for $150 off MSRP this weekend, starting at only $849. Their prices are the lowest available for new MacBook Airs today. Stock may come and go, so... Read more
Apple has 13″ M1 MacBook Airs back in stock s...
Apple has restocked a full line of 13″ M1 MacBook Airs, Certified Refurbished, starting at only $849 and up to $190 off original MSRP. These are the cheapest M1-powered MacBooks for sale today at... Read more
In stock and on sale! 16″ 10-Core M1 Pro MacB...
Amazon has new 16″ 10-Core/512GB M1 Pro MacBook Pros in stock today and on sale for $50 off MSRP including free shipping. Their prices are the lowest available for new M1 Pro 16″ MacBook Pro from any... Read more
Deal Alert!: 14″ M1 Pro with 10-Core CPU in s...
Amazon has the new 14″ M1 Pro MacBook Pro with a 10-Core CPU and 16-Core GPU in stock today and on sale for $2299.99 including free shipping. Their price is $200 off Apple’s standard MSRP, and it’s... Read more
Apple has 24-inch M1 iMacs (8-Core CPU/8-Core...
Apple has restocked a wide array of 24-inch M1 iMacs with 8-Core CPUs and 8-Core GPUs in their Certified Refurbished store. Models are available starting at only $1269 and range up to $260 off... Read more
Select 24″ M1 iMacs are on sale for $100 off...
Sales of Apple’s new 24″ M1 iMacs have been rare since its introduction, perhaps due to global supply issues. However, B&H is offering a $100 discount on select 24″ iMacs, and they’re in stock... Read more
M1 Mac minis are back in stock today at Apple...
Apple has M1-powered Mac minis available in their Certified Refurbished section starting at only $589 and up to $140 off MSRP. Each mini comes with Apple’s one-year warranty, and shipping is free: –... Read more
B&H has M1-powered Mac minis on sale for...
B&H Photo has Apple’s Mac minis with M1 Apple Silicon CPUs in stock today and on sale for $50-$100 off MSRP, starting at $649. Free 1-2 shipping is free to many US addresses. Their prices are... Read more
New Amazon sale: Apple’s 13″ M1 MacBook Airs...
Amazon has Apple 13″ M1 MacBook Airs on sale for $100 off MSRP, starting at only $899. Their prices are the lowest available for new MacBook Airs today. Stock may come and go, so check their site... Read more
Get an Apple Watch Series 7 for $50 off MSRP,...
Amazon has Apple Watch Series 7 models on sale for $50 off MSRP including free shipping. Their prices are the lowest available for Apple Watch Series 7 models today: – 41mm Apple Watch Series 7 GPS... Read more

Jobs Board

Registered Nurse (RN) Employee Health PSJH -...
…is calling for a Registered Nurse (RN) Employee Health PSJH to our location in Apple Valley, CA.** We are seeking a Registered Nurse (RN) Employee Health PSJH to be Read more
Systems Administrator - Pearson (United State...
…and troubleshoot Windows operating systems (workstation and server), laptop computers, Apple iPads, Chromebooks and printers** + **Administer and troubleshoot all Read more
IT Assistant Level 1- IT Desktop Support Anal...
…providing tier-1 or better IT help desk support in a large Windows and Apple environment * Experience using IT Service Desk Management Software * Knowledge of IT Read more
Human Resources Business Partner PSJH - Provi...
…**is calling a** **Human Resources Business Partner, PSJH** **to our location in Apple Valley, CA.** **Applicants that meet qualifications will receive a text with Read more
Manager Community Health Investment Programs...
…is calling a Manager Community Health Investment Programs PSJH to our location in Apple Valley, CA.** **Qualified candidates will be invited to do a self-paced video Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.