Cocoa Internals/Memory Management

All Objective-C objects are reference counted objects. Once the count reaches zero - the object is freed.

The modern Objective-C (or Swift) recommends (strongly, fiercely) to use Automatic-Reference-Counting (ARC) support. FPC support for Objective-C was started way before ARC became highly recommended and was part of the language. Right now Objective-C 2.0 syntax provides the language level support for ARC, while FPC doesn't have those (yet?). All Cocoa Widgetset code cannot doesn't rely on ARC and using reference and dereference manually.

Memory Management

As mentioned earlier - all Cocoa objects are reference counted objects. They should be allocated via a class constructor (typically alloc()) and be released via release() method (rather than calling a "destructor" dealloc).

Consider the following code example:

A new sub-class of NSObject is declared, overriding its alloc (constructor) and dealloc (destructor) methods. Overridden methods are providing a logging output.

program project1;

{$mode delphi}{$H+}
{$modeswitch objectivec1}
{$modeswitch objectivec2}

uses CocoaAll;

type

  { NSMyObject }

  NSMyObject = objcclass(NSObject)
  public
    class function alloc: id; override;
    procedure dealloc; override;
  end;

{ NSMyObject }

class function NSMyObject.alloc: id;
begin
  Result:=inherited alloc;
  writeln('alloc:   ', PtrUInt(Result));
end;

procedure NSMyObject.dealloc;
begin
  writeln('dealloc: ', PtrUInt(Self));
  inherited dealloc;
end;

procedure MakeObject;
var
  obj : NSMyObject;
begin
  obj:=NSMyObject.alloc.init;
  obj.release;
end;

begin
  MakeObject;
  MakeObject;
  MakeObject;
end.

The output of calling such process would be:

alloc:   3206800
dealloc: 3206800
alloc:   3206800
dealloc: 3206800
alloc:   3206800
dealloc: 3206800

This is happening, because whenever an object is allocated, it's reference count is set to 1. Calling release method reduced the reference counter by 1. If reference count becomes zero, objc runtime - is calling objects destructor - dealloc.

Leaking

If MakeObject procedure is modified as following:

procedure MakeObject;
var
  obj : NSMyObject;
begin
  obj:=NSMyObject.alloc.init;
  // removed the line with .release call
end;

the output of the application changes to:

alloc:   2146560 
alloc:   2146288 
alloc:   2146304

That looks like a memory leak via ObjC objects, because allocated objects were not released.

Preventing a leak requires a proper release of an object.

Autorelease Pools

In order to decrease a complexity of tracking of object life-span and releasing, Cocoa provides an autorelease mechanism. Any object registered in with an autorelease pool, would be released at the time autorelease pool is drained and the object's reference count is equal to 1.

(Autorelease pools are drained whenever they're released).

Let's modify the example above in the following manner:

procedure MakeObject;
var
  obj : NSMyObject;
begin
  obj:=NSMyObject.alloc.init.autorelease; // registering the allocated object with autorelease pool
end;

var
  pool : NSAutoreleasePool;
begin
  pool := NSAutoreleasePool.alloc.init;
  MakeObject;
  MakeObject;
  MakeObject;
  writeln('done!');
  pool.release;
end.

ObjC Object Leaks

Free Pascal debugging unit heaptrc is only able to track leaking of memory allocated via Pascal Run-time memory management. It's not able to track allocations made via C-runtime/Obj-C memory manager.

Apple provides an external tools to keep tracking of ObjC allocations.

Xcode Instruments

One of the

See Also

• Cocoa Internals
• Advanced Memory Management - at Apple Developer