Unveiling iOS AutoreleasePool Changes: TLS Magic and Compiler Optimizations

AutoreleasePool in main.m

In Xcode 11 the template main.m changed. The previous implementation created an autorelease pool around the UIApplicationMain call, causing the appDelegateClassName object to remain in the heap and never be released because UIApplicationMain never returns.

The old main function looked like:

int main(int argc, char *argv[]) {
  void *pool = objc_autoreleasePoolPush();
  NSString *appDelegateClassName = NSStringFromClass([AppDelegate class]);
  name = objc_autoreleaseReturnValue(appDelegateClassName);
  name = objc_retainAutoreleasedReturnValue(appDelegateClassName);
  int tmp = UIApplicationMain(argc, argv, nil, appDelegateClassName);
  objc_release(appDelegateClassName);
  objc_autoreleasePoolPop(pool);
  return tmp;
}

In reality this caused two problems: UIApplicationMain never returns, so the appDelegateClassName object stays allocated, leading to a memory leak.

When the program terminates the system reclaims the memory, making the pool drain meaningless.

The new template separates the creation of appDelegateClassName from the UIApplicationMain call:

int main(int argc, char *argv[]) {
  NSString *appDelegateClassName;
  void *pool = objc_autoreleasePoolPush();
  appDelegateClassName = NSStringFromClass([AppDelegate class]);
  appDelegateClassName = objc_autoreleaseReturnValue(appDelegateClassName);
  appDelegateClassName = objc_retainAutoreleasedReturnValue(appDelegateClassName);
  objc_release(nil);
  objc_autoreleasePoolPop(pool);
  int tmp = UIApplicationMain(argc, argv, nil, appDelegateClassName);
  objc_storeStrong(&appDelegateClassName, nil);
  return tmp;
}

Even with this change the appDelegateClassName object is not released until after UIApplicationMain finishes, which still does not happen in normal execution.

Thread Local Storage

The optimization relies on Thread‑Local Storage (TLS). On arm64, objc_autoreleaseReturnValue checks the return address with __builtin_return_address(0). If the instruction at that address is the no‑op mov fp, fp, the runtime stores a marker (value 0x1) under the key RETURN_DISPOSITION_KEY in TLS and returns the object directly, skipping objc_autorelease.

// NSObject.mm
id objc_autoreleaseReturnValue(id obj) {
    if (prepareOptimizedReturn(ReturnAtPlus1)) return obj;
    return objc_autorelease(obj);
}

// objc-object.h
enum ReturnDisposition : bool { ReturnAtPlus0 = false, ReturnAtPlus1 = true };

static ALWAYS_INLINE bool prepareOptimizedReturn(ReturnDisposition disposition) {
    if (callerAcceptsOptimizedReturn(__builtin_return_address(0))) {
        if (disposition) setReturnDisposition(disposition);
        return true;
    }
    return false;
}

static ALWAYS_INLINE bool callerAcceptsOptimizedReturn(const void *ra) {
    // mov fp, fp encodes as 0xaa1d03fd
    if (*(uint32_t *)ra == 0xaa1d03fd) return true;
    return false;
}

Similarly, objc_retainAutoreleasedReturnValue checks the TLS marker; if it finds the value 0x1 it returns the object without calling objc_retain.

// NSObject.mm
id objc_retainAutoreleasedReturnValue(id obj) {
    if (acceptOptimizedReturn() == ReturnAtPlus1) return obj;
    return objc_retain(obj);
}

static ALWAYS_INLINE ReturnDisposition acceptOptimizedReturn() {
    ReturnDisposition d = getReturnDisposition();
    setReturnDisposition(ReturnAtPlus0);
    return d;
}

Because of this TLS‑based optimization, factory‑created objects often bypass the autorelease pool, speeding up release.

Compiler Optimizations

When the __weak qualifier is added, the compiler inserts extra stack operations between the two runtime calls, breaking the callerAcceptsOptimizedReturn check. Consequently the object is placed into the autorelease pool.

// Without __weak
0x100072148: bl NSStringFromClass
0x10007214c: mov x29, x29 // mov fp, fp
0x100072150: bl objc_retainAutoreleasedReturnValue

// With __weak
0x1001da0b8: bl NSStringFromClass
0x1001da0bc: str x0, [sp, #0x8]
0x1001da0c0: b ...
0x1001da0c4: mov x29, x29 // mov fp, fp
0x1001da0c8: ldr x0, [sp, #0x8]
0x1001da0cc: bl objc_retainAutoreleasedReturnValue

Adjusting the Xcode build setting Optimization Level (Build Settings → Apple Clang → Code Generation) controls whether these markers appear. Using None[-O0] (Debug) keeps the markers; higher levels ( -O2, -Os) enable tail‑call elimination and other optimizations.

Tail Call Optimization

Tail‑call elimination is performed only in Release builds. The LLVM pass -tailcallelim transforms a call followed by a return into a loop, removing the extra stack frame. The pass is active for optimization levels -O2 and higher, but not for -O0 or -O1 in older clang versions.

// Example of tail‑call elimination pass description
This pass transforms calls of the current function (self recursion) followed by a return instruction with a branch to the entry of the function, creating a loop.

Conclusion

The article traced the changes in iOS main.m AutoreleasePool handling, revealed how Thread‑Local Storage and compiler optimizations cooperate to avoid unnecessary autoreleases, and showed how tail‑call elimination further refines generated code. Understanding these mechanisms helps iOS developers write more efficient memory‑aware code.