Objective-C and GNUstep provide a rich object allocation and memory management framework. Objective-C affords independent memory allocation and initialization steps for objects, and GNUstep supports three alternative schemes for memory management.
Unlike most object-oriented languages, Objective-C exposes memory allocation
for objects and initialization as two separate steps. In particular, every
class provides an ’+alloc
’ method for creating blank new instances.
However, initialization is carried out by an instance method, not a class
method. By convention, the default initialization method is ’-init
’.
The general procedure for obtaining a newly initialized object is thus:
id newObj = [[SomeClass alloc] init];
Here, the call to alloc
returns an uninitialized instance, on which
init
is then invoked. (Actually, alloc
does set all
instance variable memory to 0, and it initializes the special isa
variable mentioned earlier which points to the object’s class, allowing it to
respond to messages.) The alloc
and init
calls may be collapsed
for convenience into a single call:
id newObj = [SomeClass new];
The default implementation of new
simply calls alloc
and
init
as above, however other actions are possible. For example,
new
could be overridden to reuse an existing object and just call
init
on it (skipping the alloc
step). (Technically this kind of
instantiation management can be done inside init
as well – it
can deallocate the receiving object and return another one in its place.
However this practice is not recommended; the new
method should be
used for this instead since it avoids unnecessary memory allocation for
instances that are not used.)
In many cases you want to initialize an object with some specific information.
For example a Point
object might need to be given an x, y position.
In this case the class may define additional initializers, such as:
id pt = [[Point alloc] initWithX: 1.5 Y: 2.0];
Again, a new
method may be defined, though sometimes the word “new”
is not used in the name:
id pt = [Point newWithX: 1.5 Y: 2.0]; // alternative id pt = [Point pointAtX: 1.5 Y: 2.0];
In general the convention in Objective-C is to name initializers in a way that
is intuitive for their classes. Initialization is covered in more detail in
Instance Initialization. Finally, it is acceptable for an
init...
method to return nil
at times when insufficient memory
is available or it is passed an invalid argument; for example the argument to
the NSString
method initWithContentsOfFile:
may be an erroneous
file name.
Memory allocation for objects in GNUstep supports the ability to specify that memory is to be taken from a particular region of addressable memory. In the days that computer RAM was relatively limited, it was important to be able to ensure that parts of a large application that needed to interact with one another could be held in working memory at the same time, rather than swapping back and forth from disk. This could be done by specifying that particular objects were to be allocated from a particular region of memory, rather than scattered across all of memory at the whim of the operating system. The OS would then keep these objects in memory at one time, and swap them out at the same time, perhaps to make way for a separate portion of the application that operated mostly independently. (Think of a word processor that keeps structures for postscript generation for printing separate from those for managing widgets in the on-screen editor.)
With the growth of computer RAM and the increasing sophistication of memory management by operating systems, it is not as important these days to control the regions where memory is allocated from, however it may be of use in certain situations. For example, you may wish to save time by allocating memory in large chunks, then cutting off pieces yourself for object allocation. If you know you are going to be allocating large numbers of objects of a certain size, it may pay to create a zone that allocates memory in multiples of this size. The GNUstep/Objective-C mechanisms supporting memory allocation are therefore described here.
The fundamental structure describing a region of memory in GNUstep is called a
Zone, and it is represented by the NSZone
struct. All
NSObject
methods dealing with the allocation of memory optionally take
an NSZone
argument specifying the Zone to get the memory from. For
example, in addition to the fundamental alloc
method described above,
there is the allocWithZone:
method:
+ (id) alloc; + (id) allocWithZone: (NSZone*)zone;
Both methods will allocate memory to hold an object, however the first one
automatically takes the memory from a default Zone (which is returned by the
NSDefaultMallocZone()
function). When it is necessary to group objects
in the same area of memory, or allocate in chunks - perhaps for performance
reasons, you may create a Zone from where you would allocate those objects by
using the NSCreateZone
function. This will minimise the paging
required by your application when accessing those objects frequently.
In all normal use however, you should confine yourself to the default zone.
Low level memory allocation is performed by the NSAllocateObject()
function. This is rarely used but available when you require more advanced
control or performance. This function is called by [NSObject
+allocWithZone:]
. However, if you call NSAllocateObject()
directly to
create an instance of a class you did not write, you may break some
functionality of that class, such as caching of frequently used objects.
Other NSObject
methods besides alloc
that may optionally take
Zones include -copy
and -mutableCopy
. For 95% of cases you
will probably not need to worry about Zones at all; unless performance is
critical, you can just use the methods without zone arguments, that take the
default zone.
With the ObjC-2 (NG) setup, the use of zones is obsoleted: the runtime library performs the actual allocation of objects and ignores the zone information.
Objects should be deallocated from memory when they are no longer needed.
While there are several alternative schemes for managing this process (see
next section), they all eventually resort to calling the NSObject
method -dealloc
, which is more or less the opposite of -alloc
.
It returns the memory occupied by the object to the Zone from which it was
originally allocated. The NSObject
implementation of the method
deallocates only instance variables. Additional allocated, unshared memory
used by the object must be deallocated separately. Other entities that depend
solely on the deallocated receiver, including complete objects, must also be
deallocated separately. Usually this is done by subclasses overriding
-dealloc
(see Instance Deallocation).
As with alloc
, the underlying implementation utilizes a function
(NSDeallocateObject()
) that can be used by your code if you know what
you are doing.
With the ObjC-2 (NG) setup, the use of zones is obsoleted: the runtime library performs the freeing of memory used by objects.
In an object-oriented environment, ensuring that all memory is freed when it is no longer needed can be a challenge. To assist in this regard, there are three alternative forms of memory management available in Objective-C:
You allocate objects using alloc
, copy
etc, and deallocate
them when you have finished with them (using dealloc
).
This gives you complete control over memory management, and is highly
efficient, but error prone.
This is the standard route to memory management taken in C and C++ programs.
As in standard C when using malloc
, or in C++ when using new
and
delete
, you need to keep track of every object created through an
alloc
call and destroy it by use of dealloc
when it is no longer
needed. You must make sure to no longer reference deallocated objects;
although messaging them will not cause a segmentation fault as in C/C++, it
will still lead to your program behaving in unintended ways.
This approach is generally not recommended since the Retain/Release style of memory management is significantly less leak-prone while still being quite efficient.
You use the OpenStep retain/release mechanism, along with autorelease pools which provide a degree of automated memory management. This gives a good degree of control over memory management, but requires some care in following simple rules. It’s pretty efficient.
The standard OpenStep system of memory management employs retain counts. When an object is created, it has a retain count of 1. When an object is retained, the retain count is incremented. When it is released the retain count is decremented, and when the retain count goes to zero the object gets deallocated.
Coin *c = [[Coin alloc] initWithValue: 10]; // Put coin in pouch, [c retain]; // Calls 'retain' method (retain count now 2) // Remove coin from pouch [c release]; // Calls 'release' method (retain count now 1) // Drop in bottomless well [c release]; // Calls 'release' ... (retain count 0) then 'dealloc'
Retain count is best understood using the concept of ownership. When we retain an object we own it and are responsible for releasing it again. When nobody owns an object (its retain count is zero) it is deallocated. The retain count of an object is the number of places which own the object and have therefore undertaken to release it when they have finished with it.
One way of thinking about the initial retain count of 1 on the object is that
a call to alloc
(or copy
) implicitly calls retain
as
well. There are a couple of default conventions about how retain
and
release
are to be used in practice.
retain
s in a block should be
matched by an equal number of release
s.
Thus, a typical usage pattern is:
NSString *msg = [[NSString alloc] initWithString: @"Test message."]; NSLog(msg); // we created msg with alloc -- release it [msg release];
Retain and release must also be used for instance variables that are objects:
- (void) setFoo: (FooClass *newFoo) { // first, assert reference to newFoo [newFoo retain]; // now release reference to foo (do second since maybe newFoo == foo) [foo release]; // finally make the new assignment; old foo was released and may // be destroyed if retain count has reached 0 foo = newFoo; }
To write portable code (which will work with both the classic retain counting mechanism and with ARC) you should use the macros RETAIN(expr) and RELEASE(expr) along with the DESTROY(lvalue) and ASSIGN(lvalue, expr) macros.
Because of this retain/release management, it is safest to use accessor methods to set variables even within a class:
- (void) resetFoo { FooClass *foo = [[FooClass alloc] init]; [self setFoo: foo]; // since -setFoo just retained, we can and should // undo the retain done by alloc [foo release]; }
Exceptions
In practice, the extra method call overhead should be avoided in performance critical areas and the instance variable should be set directly. However in all other cases it has proven less error-prone in practice to consistently use the accessor.
There are certain situations in which the rule of having retains and releases
be equal in a block should be violated. For example, the standard
implementation of a container class retain
s each object that is added
to it, and release
s it when it is removed, in a separate method. In
general you need to be careful in these cases that retains and releases match.
Only available when using the ObjC-2 (NG) environment rather than classic Objective-C. In this case the compiler generates code to use the retain count and autorelease pools. The use of ARC can be turned on/off for individual files.
The automation of retain and release makes for much more reliable memory management but can still be broken by failure to annotate methods and functions which do anything unusual, as well as failing to handle certain patterns of using such as retain cycles.
Despite the advantages of ARC, this is only available with one compiler/runtime and code dependent on ARC is therefore inherently non-portable. To make portable code which is more robust in the long run, it is therefore recommended that you use the portability macros (described later) to produce code which will work with both the basic OpenStep style manual retain/release and with ARC..
One important case where the retain/release system has difficulties is when
an object needs to be transferred or handed off to another. You don’t want
to retain the transferred object in the transferring code, but neither do you
want the object to be destroyed before the hand-off can take place. The
OpenStep/GNUstep solution to this is the autorelease pool. An
autorelease pool is a special mechanism that will retain objects it is given
for a limited time – always enough for a transfer to take place. This
mechanism is accessed by calling autorelease
on an object instead of
release
. Autorelease
first adds the object to the active
autorelease pool, which retains it, then sends a release
to the object.
At some point later on (when the pool is destroyed), the pool will send the
object a second release
message, but by this time the object will
presumably either have been retained by some other code, or is no longer
needed and can thus be deallocated. For example:
- (NSString *) getStatus { NSString *status = [[NSString alloc] initWithFormat: "Count is %d", [self getCount]]; // set to be released sometime in the future [status autorelease]; return status; }
Any block of code that calls -getStatus
can also forego retaining the
return value if it just needs to use it locally. If the return value is to be
stored and used later on however, it should be retained:
... NSString *status = [foo getStatus]; // 'status' is still being retained by the autorelease pool NSLog(status); return; // status will be released automatically later
... currentStatus = [foo getStatus]; // currentStatus is an instance variable; we do not want its value // to be destroyed when the autorelease pool cleans up, so we // retain it ourselves [currentStatus retain];
To write portable code (for both classic retain counting and ARC) you should use the AUTORELEASE(expr) macro.
Convenience Constructors
A special case of object transfer occurs when a convenience constructor is
called (instead of alloc
followed by init
) to create an object.
(Convenience constructors are class methods that create a new instance and do
not start with “new”.) In this case, since the convenience method is the
one calling alloc
, it is responsible for releasing it, and it does so
by calling autorelease
before returning. Thus, if you receive an
object created by any convenience method, it is autoreleased, so you don’t
need to release it if you are just using it temporarily, and you DO need to
retain it if you want to hold onto it for a while.
- (NSString *) getStatus { NSString *status = [NSString stringWithFormat: "Count is %d", [self getCount]]; // 'status' has been autoreleased already return status; }
Pool Management
An autorelease pool is created automatically if you are using the GNUstep GUI classes, however if you are just using the GNUstep Base classes for a non-graphical application, you must create and release autorelease pools yourself:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
Once a pool has been created, any autorelease calls will automatically find it. To close out a pool, releasing all of its objects, simply release the pool itself:
[pool release];
To achieve finer control over autorelease behaviour you may also create
additional pools and release them in a nested manner. Calls to
autorelease
will always use the most recently created pool.
Finally, note that autorelease
calls are significantly slower than
plain release
. Therefore you should only use them when they are
necessary.
The best way to manage autorelease pools is using macros which will work both for the classic system or when using ARC. The ENTER_POOL macro begins a block in which a new pool handles autoreleases and the LEAVE_POOL macro ends that block and destroys the autorelease pool.
One difficulty that sometimes occurs with the retain/release system is that cycles can arise in which, essentially, Object A has retained Object B, and Object B has also retained Object A. In this situation, neither A nor B will ever be deallocated, even if they become completely disconnected from the rest of the program. In practice this type of situation may involve more than two objects and multiple retain links. The only way to avoid such cycles is to be careful with your designs. If you notice a situation where a retain cycle could arise, remove at least one of the links in the chain, but not in such a way that references to deallocated objects might be mistakenly used.
To help solve the problem of retain cycles you can use weak references to break a cycle. The runtime library provides functions to handle weak references so that you can safely check to see whether the reference is to an object that still exists or not. To manage that the objc_storeWeak() function is used whenever assigning a value to the variable (instead of retaining the value), and the objc_loadWeak() function is used to retrieve the value from the variable ... the retrieved value will be nil if the object has been deallocated. With the ObjC-2 (Next Generation) environment you can use the keyword ‘weak’ to tell the compiler to automatically insert calls to those runtime functions whenever a value is written to or read from the variable. NB. weak references are relatively inefficient since each time objc_loadWeak() is called it both retains and autorelease the referenced value so that it will continue to exist for long enough for your code to work with it.
Consider a simple case of leaked objects in a program a.m
built with the
asan=yes
make option. The code looks like this:
#import <Foundation/Foundation.h> int main(void) { id obj; obj = [[NSString alloc] initWithString: @"hello"]; obj = [[NSArray alloc] initWithObjects: &obj count: 1]; return 0; }
The program creates an NSString and then creates an NSArray containing that string, before exiting without releasing either, so both are leaked.
The leak sanitizer log on program exist looked like this:
================================================================= ==411363==ERROR: LeakSanitizer: detected memory leaks Direct leak of 28 byte(s) in 1 object(s) allocated from: #0 0x... in calloc (/home/user/a+0x...) #1 0x... in allocate_class libobjc2/gc_none.c:19:3 #2 0x... in class_createInstance libobjc2/runtime.c:361:11 #3 0x... in NSAllocateObject Source/NSObject.m:800:14 #4 0x... in _i_GSPlaceholderArray__initWithObjects_count_ Source/GSArray.m:1257:14 #5 0x... in main /home/user/a.m:9:9 #6 0x... in __libc_start_call_main libc_start_call_main.h:58:16 #7 0x... in __libc_start_main libc-start.c:360:3 #8 0x... in _start (/home/user/obj/a+0x...)
This is just the first part, giving the stack trace of a direct leak (memory with nothing pointing to it): occurring at /home/user/a.m line 9 column 9. Clearly this is telling us that the array was leaked.
Indirect leak of 42 byte(s) in 1 object(s) allocated from: #0 0x... in calloc (/home/user/obj/a+0x...) #1 0x... in allocate_class libobjc2/gc_none.c:19:3 #2 0x... in class_createInstance libobjc2/runtime.c:361:11 #3 0x... in NSAllocateObject Source/NSObject.m:800:14 #4 0x... in newUInline Source/GSString.m:755:5 #5 0x... in _i_GSPlaceholderString__initWithString_ Source/GSString.m:1727:19 #6 0x... in main /home/user/a.m:8:9 #7 0x... in __libc_start_call_main libc_start_call_main.h:58:16 #8 0x... in __libc_start_main c-start.c:360:3 #9 0x... in _start (/home/user/obj/a+0x...)
This second part of the report is an indirect leak (because it is memory which is pointed to by the leaked array). It’s the NSString object created at /home/user/a.m line 8 column 9.
Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x... in malloc (/home/user/obj/a+0x...) #1 0x... in default_malloc Source/NSZone.m:164:9 #2 0x... in NSZoneMalloc Source/NSZone.m:1802:10 #3 0x... in _i_GSArray__initWithObjects_count_ Source/GSArray.m:186:25 #4 0x... in _i_GSPlaceholderArray__initWithObjects_count_ Source/GSArray.m:1268:10 #5 0x... in main /home/user/a.m:9:9 #6 0x... in __libc_start_call_main libc_start_call_main.h:58:16 #7 0x... in __libc_start_main libc-start.c:360:3 #8 0x... in _start (/home/user/obj/a+0x...)
This third part is also an indirect leak ... it’s the backing store allocated to hold the object in the array, so fixing the leak of the array object should also fix this (since the array should free its backing store when it is done with it).
SUMMARY: AddressSanitizer: 78 byte(s) leaked in 3 allocation(s).
The final part of the leak report is the summary. In a big leak report you can quickly look to the end of the report to get an idea of the severity of leaks in your program.
In this trivial example it is easy to see, from the stack traces, exactly where the problems lie. In a more realistic situation the leak sanitizer tells you exactly where leaked memory was allocated, but it can still be very had to tell why that memory was not deallocated later ... a leaked object may have been retained, autoreleased and released multiple times during the life of the program as it is passed around between different sections of code and temporarily held in different data structures.
If the leak sanitizer has detected a leak, but you can’t figure out why the leak occurred from simple source code inspection, the gnustep-base library can help you.
The GNUstepBase/NSObject+GNUstepBase.h
header contains the
-trackOwnership method for tracking object lifecycles. Immediately after the
leaked object is allocated you can add code to send it the trackOwnership
message, and a stack trace will be logged every time that object is retained,
or released (or deallocated), allowing you to see what happened to it from the
start of its life to the point where the program exited.
#import <Foundation/Foundation.h> #import <GNUstepBase/NSObject+GNUstepBase.h> @interface Leaked : NSObject @end @implementation Leaked @end @interface ItemHolder : NSObject { NSObject *i; } + (ItemHolder*) holderFor: (NSObject*)anItem; - (NSObject*) item; @end @implementation ItemHolder + (ItemHolder*) holderFor: (NSObject*)anItem { ItemHolder *h = [self new]; ASSIGN(h->i, anItem); return AUTORELEASE(h); } - (NSObject*) item { return i; } @end int main(void) { ENTER_POOL NSObject *leaked = [Leaked new]; [leaked trackOwnership]; [NSArray arrayWithObject: [ItemHolder holderFor: leaked]]; DESTROY(leaked); LEAVE_POOL return 0; }
In this slightly more realistic example, the leaked instance of a new class
called Leaked
is explicitly destroyed, and the code is inside an
autorelease pool so the cause of the leak is a little less obvious.
Tracking ownership started for instance 0x... at ( "... _i_NSObject_GSCleanUp_trackOwnership Source/Additions/NSObject+GNUstepBase.m: 827", "(./obj/a: 0x...) main /home/user/a.m: 36", "(/libc.so.6: 0x...) __libc_start_call_main libc-start.c: 74", "(libc.so.6: 0x...) call_init libc-start.c: 128", "(./obj/a: 0x...) _start (null): 0"). Tracking ownership -[0x50200008e858 retain] 1->2 at ( "(./obj/a: 0x...) _c_ItemHolder__holderFor_ /a.m: 21", "(./obj/a: 0x...) main /a.m: 37", "(libc.so.6: 0x...) __libc_start_call_main libc-start.c: 74", "(libc.so.6: 0x...) call_init libc-start.c: 128", "(./obj/a: 0x...) _start (null): 0"). Tracking ownership -[0x50200008e858 release] 2->1 at ( "(./obj/a: 0x...) main /a.m: 39", "(libc.so.6: 0x...) __libc_start_call_main libc-start.c: 74", "(libc.so.6: 0x...) call_init libc-start.c: 128", "(./obj/a: 0x...) _start (null): 0"). Tracking ownership -[0x50200008e858 dealloc] not called by exit.
The trace for the leaked object is edited to leave out some file path details etc for clarity, so you can see there are four logs; start of tracking, a retain, a release, and the end of the program.
In each log the address of the traced object is shown (so if you are tracking more than one object you can tell which logs are which) along with the operation being traced.
For the retain log, the address and operation information is followed by 1->2 indicating that the retain count of the object changed from 1 to 2, and from the stack trace we can see that the retain was done by the +holderFor: method.
For the release log, the address and operation information is followed by 2->1 indicating that the retain count of the object changed from 1 to 1, and from the stack trace we can see that the release was done at line 39 in main.m (the -release produced by the DESTROY() macro).
From this it’s quite easy to see that the leaked object was NOT released when the ItemHolder was deallocated, so we now what we need to release it in the -dealloc method of ItemHolder (forgetting to do this is a common error, and is something that ARC would do for us automatically).
A portable fix would be to add an implementation as follows:
- (void) dealloc { RELEASE(i); DEALLOC }
Wonderful as leak sanitization is, it is far from perfect. It is subject to false positives, where things are reported as leaks which were intentionally leaked (eg because they are insignificant), often in library code that you don’t really have much control over. To handle that the sanitizer has a suppression mechanism where a file can be specified to contain rules that the sanitizer will use to suppress reporting of false positives. You need to refer to the LeakSanitizer documentation for the details of that.
The report is also governed by what it considers a leak (which may not be what you think is a leak). The general principle is that heap memory which is not reachable (either directly or indirectly) from some standard locations is considered leaked, but the exact definition of the standard locations vary. Usually global variables, static variables, and variables on the stack may all be pointers to memory that prevent the memory from being considered leaks.
There is also the consideration that often memory we would consider leaked (because it contributes to an ever expanding memory footprint of a long running process) is not considered leaked by the sanitiser simply because it is pointed to from within some data structure which is in use. The leak sanitizer cannot help in this case unless you suspect the problem and deliberately leak that data structure (in which case the sanitizer can help by reporting where the items still in the data structure were created).
Looking at the following code:
#import <Foundation/Foundation.h> #import "Client.h" @implementation Client - (void) executeCallSequence { NSString *str = [NSString stringWithFormat: @"one little string: %d\n", 100]; const char *strCharPtr = [str cString]; } @end int main(int argv, char** argc) { Client *client = [[Client alloc] init]; [[NSAutoreleasePool alloc] init]; [client executeCallSequence]; return 0; }
So, what do we expect this to do if we build the program with leak checking (’make asan=yes’) or run it with a separate leak checker such as valgrind?
Firstly this code creates a Client instance, owned by the main function. This is because +alloc returns an instance owned by the caller, and -init consumes its receiver and returns an instance owned by the caller, so the alloc/init sequence produces an instance owned by the main function.
Next it creates/enters an autorelease pool, owned by the main function.
Next it executes the method ’-[Client executeCallSequence]’ which:
Creates an NSString which is NOT owned by the method.
The +stringWithFormat: method creates a new instance and adds it to the current autorelease pool before returning it.
Creates a C string, which is NOT owned by the method.
A non-object return value can’t be retained or released, but it conforms to the convention that the memory is not owned by the caller, so the caller need not free it. The -cString method is free to manage that however it likes (for instance it might return a pointer to some internal memory which exists until the NSString object is deallocated), but typically what’s returned is a pointer to memory inside some other object which has been autoreleased.
Finally, the ’return’ command means that the program exits with a status of zero.
A simple look at the basic retain count and autorelease rules would say that all the memory is leaked (because the program contains no call to release anything), but there’s a bit of behind the scenes magic: when a thread exits it releases all the autorelease pools created in it which were not already released. That’s not to say that the failure to release the autorelease pool was not a bug (the code should have released it), just that there is a fail-safe behaviour to protect multithreaded programs from this particular programmer error.
So when you consider that, you can see that the autorelease pool is deallocated so the memory of the pool is actually freed, and the memory of the NSString and C-String inside it are therefore also freed.
This leaves us with the memory of the Client object being leaked. However, the idea that any unfreed memory is a leak is too simplistic (leak checkers would be useless if they reported so much) so the leak checker only reports some unfreed memory ... stuff that can’t be reached from various standard routes. The main case is that anything pointed to by global or static variables is not considered leaked, but also anything pointed to by a variable in the main() function is not considered leaked. This is why the Client instance would not normally be reported by a leak checker.