mikeash.com pyblog/friday-qa-2010-12-17-custom-object-allocators-in-objective-c.html comments

mikeash - 2014-05-24 02:58:09

Sat, 24 May 2014 02:58:09 GMT

Without looking at the code in detail (sorry), you should be safe as long as you call objc_destructInstance. Fortunately, this call has been made public since I wrote this article, and is now the officially supported way to destroy an object while managing the memory yourself. objc_constructInstance is probably also a good idea to use. If using the two of those still runs into trouble, I'd encourage filing a bug. This is something the runtime guys do care about (I think my prodding helped get these calls made public, and it didn't strike me as their intent to break custom allocations in the first place when I talked to them) and I think they'll get it fixed if it's broken.

mmarino - 2014-05-19 16:25:47

Mon, 19 May 2014 16:25:47 GMT

First of all, apologies for posting on a 3-year-old blog entry, but this seems to be the standard reference for custom object allocations in obj-c.

This seems to not be possible with recent versions of obj-c. In particular, the run-time keeps track of whether or not [NSObject release] has been called on an object. See, e.g.:

http://www.opensource.apple.com/source/objc4/objc4-551.1/runtime/NSObject.mm

and in particular

bool
_objc_rootReleaseWasZero(id obj)

where the SpinTable keeps track of whether or not release has been called (it sets SIDE_TABLE_DEALLOCATING). I have not tried to work around this, but certainly it's possible to call another function than release to send the object back to the cache.

yaniv - 2013-02-05 13:28:52

Tue, 05 Feb 2013 13:28:52 GMT

Can someone please explain me what this syntax exactly means:
*(id *)cachedObj

Thanks !

mikeash - 2011-01-14 16:21:16

Fri, 14 Jan 2011 16:21:16 GMT

Good point. You'll probably want to round the size up to the nearest multiple of sizeof(void *) to be safe.

johne - 2011-01-14 12:17:01

Fri, 14 Jan 2011 12:17:01 GMT

There's a potential problem with AllocateNewBlockAndCache, namely that you use the size returned by class_getInstanceSize(class) to "slice" up the allocation. To the best of my knowledge, the size returned by class_getInstanceSize() is not rounded up to the ABI required minimum boundary for correct alignment.

The allocation returned by malloc() is required to return an allocation that is guaranteed to be correctly aligned for any type. Correct alignment is (probably) not guaranteed as it is currently written. Whether or not this is a problem depends on the architecture. It will probably work on x86, but not on RISCy CPUs.

Nathan de Vries - 2011-01-14 03:05:04

Fri, 14 Jan 2011 03:05:04 GMT

Just found this tidbit in the Memory Usage Performance Guidelines [1]:

The calloc function reserves the required virtual address space for the memory but waits until the memory is actually used before initializing it. This approach is much more efficient than using memset, which forces the virtual memory system to map the corresponding pages into physical memory in order to zero-initialize them. Another advantage of using the calloc function is that it lets the system initialize pages as they’re used, as opposed to all at once.

I'd always assumed that using malloc + memset was functionally equivalent to using calloc. Not true, it seems!

[1] http://developer.apple.com/library/mac/#documentation/Performance/Conceptual/ManagingMemory/Articles/MemoryAlloc.html

mikeash - 2011-01-13 16:54:09

Thu, 13 Jan 2011 16:54:09 GMT

As far as I know, yes, malloc does optimistic allocation. It will only ever return NULL if you're out of address space.

As for calloc, I never pay attention to the arguments, and just leave one as 1. The fact that the zeroing and non-zeroing allocation calls take different size arguments has never made any sense to me....

Nathan de Vries - 2011-01-13 06:36:51

Thu, 13 Jan 2011 06:36:51 GMT

Very useful article — thanks Mike. Out of interest, do you know whether malloc uses an optimistic memory allocation strategy?

Also, while it doesn't make a difference, calloc's API is:

void * calloc(size_t count, size_t size);

You've flipped the arguments:

id obj = calloc(class_getInstanceSize(self), 1);

It should read:

id obj = calloc(1, class_getInstanceSize(self));

Cheers,

Nathan de Vries

johne - 2011-01-11 19:35:06

Tue, 11 Jan 2011 19:35:06 GMT

You can make this thread safe with OSAtomicEnqueue() and OSAtomicDequeue(). Basically,

replace
static id gCacheListHead;
with
static OSQueueHead gCacheListHead = OS_ATOMIC_QUEUE_INIT;

then replace
static id GetObjectFromCache(void) { }
with
static id GetObjectFromCache(void) { return(OSAtomicDequeue(&gCacheListHead, offsetof(id, isa))); }

and finally replace
static void AddObjectToCache(id obj) { }
with
static void AddObjectToCache(id obj) { OSAtomicEnqueue(&gCacheListHead, obj, offsetof(id, isa)); }

Completely untested, but that's the general idea. This will provide a thread-safe atomic LIFO queue, even when multiple CPU's are concurrently adding and removing items.

Camille - 2010-12-19 01:15:06

Sun, 19 Dec 2010 01:15:06 GMT

Very nice article, thanks Mike!

iamleeg - 2010-12-18 16:58:16

Sat, 18 Dec 2010 16:58:16 GMT

Another reason you might want to build a custom allocator: working with crypto code and you want to zero out the memory used in -dealloc. It can get easier just to define a new allocator and grab your 'sensitive' memory in any API from it.

mikeash - 2010-12-17 22:17:22

Fri, 17 Dec 2010 22:17:22 GMT

Nah, that's handled in +allocWithZone:. It could go either place, but putting it there makes it easier to deal with (same-sized) subclasses.

Seth Willits - 2010-12-17 21:53:37

Fri, 17 Dec 2010 21:53:37 GMT

Err, make that if (obj) *(Class *)obj = [MyObject class];

Seth Willits - 2010-12-17 21:49:34

Fri, 17 Dec 2010 21:49:34 GMT

GetObjectFromCache also needs to reset the isa pointer.



    *(Class *)obj = [MyObject class];

    return obj;

mikeash - 2010-12-17 21:44:33

Fri, 17 Dec 2010 21:44:33 GMT

Thanks for that, fixed now.

Seth Willits - 2010-12-17 21:01:30

Fri, 17 Dec 2010 21:01:30 GMT

GetObjectFromCache and AddObjectToCache are declared to return id, but don't.