自定义对象内存分配器

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-object-allocators-in-objective-c.html

Merry holidays, happy winter, and a joyous Friday Q&A to you all. Camille Troillard suggested that I discuss how to create custom object memory allocators in Objective-C, and today I’m going to walk through how to accomplish this and why you might want to.

What It Means As anyone who uses Objective-C knows, you allocate an instance of a class by writing [MyClass alloc]. Creating a custom allocator simply means that replace the standard allocator so that [MyClass alloc] calls into your own code instead.

An Objective-C object is just a chunk of memory with the right size, and with the first pointer-sized chunk set to point at the object’s class. A custom allocator thus needs to return a pointer to a properly-sized chunk of memory, with the class filled out appropriately.

Why It’s Useful By far the largest reason to write a custom allocator is for performance. The standard allocator makes tradeoffs which may not be appropriate for your particular case. It also has to work with every class in every situation, whereas your custom allocator only needs to work with your class and the situations it’s used in.

Another reason is overhead. The standard allocator requires a certain amount of extra storage for each allocation for various reasons. This can be particularly expensive for very small objects allocated in very large numbers. A custom allocator can cut down on this overhead substantially by tailoring it to the needs of the class it’s written for.

A Note on Garbage Collection This post assumes manual retain/release memory management. Custom allocators are mostly impossible to use under garbage collection, because there is no way to add a custom free callback. It is possible to use some of these techniques (like an object cache) but for the most part, custom allocators are reserved for the realm of manual memory management.

A Basic Custom Allocator The +alloc method actually just calls through to +allocWithZone:. Although memory zones are pretty much just a historical curiosity at this point, they remain in the API. Thus the method to override is +allocWithZone::

1
    + (id)allocWithZone: (NSZone *)zone
2
    {

In order to call calloc, you need to know how much memory to allocate. Fortunately, the Objective-C runtime makes it easy. The class_getInstanceSize function will tell you exactly this:

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

1
        *(Class *)obj = self;

1
        return obj;
2
    }

1
    - (void)dealloc
2
    {
3
        free(self);

1
        return;
2
        [super dealloc]; // shut up compiler
3
    }

Gotchas As with most things at this level, there are a few things to watch out for.

First, don’t do this unless you subclass NSObject directly. The -dealloc method covers both destroying the object itself, and freeing resources it holds. -[NSObject dealloc] just destroys the object (mostly) so it’s safe not to call it. It’s not safe to do this for any other class, though. For example, if you tried this with an NSView subclass, you’d end up leaking a whole bunch of internal state.

Second, the “(mostly)” from above means there are some things that NSObject does that you need to think about. One is removing associated objects. If your objects may have associated objects, or you think there’s even a chance that it might, then you need to make sure they’re removed. This can be done by calling objc_removeAssociatedObjects(self). The other is calling destructors for C++ objects in instance variables. Your best bet here is to just avoid having C++ objects as instance variables. If you must have them, look into the possibility of calling or imitating the private runtime function objc_destructInstance, which takes care of both C++ destructors and associated objects.

Third, memory debugging tools like ObjectAlloc and zombies won’t work on objects with a custom allocator. For this reason, I recommend that you have a memory debugging preprocessor define which makes your objects use the standard allocator instead of your custom allocator, so that you can flip the switch and use these tools if need be.

Caching Objects For a realistic example, I’ll write an allocator that places destroyed objects in a cache so that they can be quickly reused. This sort of thing is useful for classes which are allocated and destroyed so frequently that the standard allocator is too slow.

In order to reach maximum speed, I’ll make a few assumptions about how this class works and is used:

• It is never subclassed, or if it is, subclasses never add instance variables. (This allows it to put all instances in the same cache.)

• Its initializer methods can deal with a “dirty” object; i.e. the instance variables don’t need to be zeroed out. (This saves time zeroing out each instance when pulling it out of the cache.)

• It is only ever allocated and destroyed from the same thread. (This makes it unnecessary to create a thread-safe cache.)

1
    + (id)allocWithZone: (NSZone *)zone
2
    {
3
        id obj = GetObjectFromCache();
4
        if(obj)
5
            *(Class *)obj = self;
6
        else
7
            obj = [super allocWithZone: zone];
8
        return obj;
9
    }

1
    - (void)dealloc
2
    {
3
        // release any ivars here
4
        AddObjectToCache(self);
5

6
        // shut up the compiler
7
        return;
8
        [super dealloc];
9
    }

1
    static id gCacheListHead;

1
    static id GetNext(id cachedObj)
2
    {
3
        return *(id *)cachedObj;
4
    }
5

6
    static void SetNext(id cachedObj, id next)
7
    {
8
        *(id *)cachedObj = next;
9
    }

1
    static id GetObjectFromCache(void)
2
    {
3
        id obj = gCacheListHead;
4
        if(obj)
5
            gCacheListHead = GetNext(obj);
6
        return obj;
7
    }
8

9
    static void AddObjectToCache(id obj)
10
    {
11
        SetNext(obj, gCacheListHead);
12
        gCacheListHead = obj;
13
    }

Custom Block Allocator Caching objects can be a big speed boost, but the initial allocations are not accelerated, and you still have the space overhead of all of those small allocations. By allocating a large block of memory and chopping it up into chunks, it’s possible to speed up the initial allocations and vastly decrease the per-object overhead. To do this, I’ll use the same object cache scheme as above, but with a modification to the +allocWithZone: implementation:

1
    + (id)allocWithZone: (NSZone *)zone
2
    {
3
        id obj = GetObjectFromCache();
4
        if(!obj)
5
        {
6
            AllocateNewBlockAndCache(self);
7
            obj = GetObjectFromCache();
8
        }
9
        *(Class *)obj = self;
10
        return obj;
11
    }

1
    static void AllocateNewBlockAndCache(Class class)
2
    {
3
        static size_t kBlockSize = 4096;
4
        char *newBlock = malloc(kBlockSize);

1
        int instanceSize = class_getInstanceSize(class);
2
        int instanceCount = kBlockSize / instanceSize;
3
        while(instanceCount-- > 0)
4
        {
5
            AddObjectToCache((id)newBlock);
6
            newBlock += instanceSize;
7
        }
8
    }

Conclusion Writing a custom object allocator in Objective-C is relatively simple. The hard part is the allocator itself, which is largely up to you. Once you have the allocator, you can plug it into your Objective-C class by:

• Overriding +allocWithZone: to call your custom allocator, set the isa of the block to self, and optionally zero out the rest of the memory.

• Overriding -dealloc to call your custom allocator, and do not call through to super.

• Calling objc_removeAssociatedObjects in -dealloc if there’s a chance of your object containing associated objects.

• Only subclassing NSObject directly, and not subclassing any subclass of NSObject.

That’s it for this edition of Friday Q&A. Come back in two weeks for the next exciting edition. As always, your ideas for topics to cover are welcome and requested, so if you have something that you would like to see covered here, please send it in!