Understanding the AutoreleasePool Mechanism in Objective‑C

In ARC, AutoreleasePool is used to control memory peaks when many temporary objects are created; the pool collects objects marked for delayed release and releases them together. Under MRC, NSAutoreleasePool provides the same functionality, but the API is disabled when ARC is enabled.

The modern syntax @autoreleasepool is recommended by Apple because it has better performance and works both under ARC and MRC. The __autoreleasing qualifier can also be used to mark objects for delayed release in ARC.

Internally, the compiler translates @autoreleasepool into a C++ struct __AtAutoreleasePool that calls objc_autoreleasePoolPush on entry and objc_autoreleasePoolPop on exit. These functions manipulate an AutoreleasePoolPage object, which is a 4 KB page storing pointers to autoreleased objects in a doubly‑linked list.

The page structure contains a parent and child pointer, allowing the runtime to allocate additional pages when the current one fills. A special marker POOL_BOUNDARY separates different pools within the same page, enabling nested @autoreleasepool blocks to share a page while still being correctly demarcated.

When an object is autoreleased, the runtime checks whether it is a tagged pointer; if not, it calls autoreleaseFast , which either adds the object to the current page via add or creates a new page using autoreleaseFullPage or autoreleaseNoPage depending on the page’s state.

The add function stores the object at the next pointer and advances the pointer. When a pool is popped, the pop routine determines the correct page, walks backward from the top of the page, and releases each object until it reaches the POOL_BOUNDARY marker, then cleans up empty pages.

Helper functions hotPage and coldPage retrieve the current page for the thread (stored in thread‑local storage) and the root page of the linked list, respectively. Debugging can be performed with the private API _objc_autoreleasePoolPrint , which shows the number of pending releases and the layout of pages and boundaries.

In a typical iOS app, the main thread’s run‑loop automatically creates and drains an autorelease pool around each iteration. The @autoreleasepool placed around UIApplicationMain only manages objects created directly in main , while the run‑loop’s implicit pool handles objects created during event processing.

Objects created in view lifecycle methods (e.g., viewDidLoad ) are not released when the method returns; they are released either when an explicit pool block ends or when the run‑loop drains its implicit pool at the end of the current iteration.

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// ...
[pool release];

@autoreleasepool {
    // code that creates many temporary objects
}

struct __AtAutoreleasePool {
    __AtAutoreleasePool() { atautoreleasepoolobj = objc_autoreleasePoolPush(); }
    ~__AtAutoreleasePool() { objc_autoreleasePoolPop(atautoreleasepoolobj); }
    void *atautoreleasepoolobj;
};

static inline void *push() {
    id *dest;
    if (DebugPoolAllocation) {
        dest = autoreleaseNewPage(POOL_BOUNDARY);
    } else {
        dest = autoreleaseFast(POOL_BOUNDARY);
    }
    return dest;
}

static inline id *autoreleaseFast(id obj) {
    AutoreleasePoolPage *page = hotPage();
    if (page && !page->full()) {
        return page->add(obj);
    } else if (page) {
        return autoreleaseFullPage(obj, page);
    } else {
        return autoreleaseNoPage(obj);
    }
}

static inline void pop(void *token) {
    AutoreleasePoolPage *page;
    id *stop;
    if (token == (void*)EMPTY_POOL_PLACEHOLDER) {
        page = hotPage();
        if (!page) return setHotPage(nil);
        page = coldPage();
        token = page->begin();
    } else {
        page = pageForPointer(token);
    }
    stop = (id *)token;
    if (*stop != POOL_BOUNDARY) {
        if (stop == page->begin() && !page->parent) {
            // ...
        } else {
            return badPop(token);
        }
    }
    return popPage
(token, page, stop);
}