Why does returning a strong and autoreleasing variable yields different object lifecycle only after the first time?

Question

Consider this piece of code:

@implementation MyClass
-(void)dealloc {
    NSLog(@"MyClass dealloc: %@", self);
}
@end

@implementation AppDelegate

__weak static MyClass *weakShared = nil;

- (MyClass *)getMyClass {
    MyClass *tmpHolder = [[MyClass alloc] init]; // PREPEND "__autoreleasing"
    weakShared = tmpHolder;
    return weakShared; // ATTENTION TO THIS LINE
}
- (void)logMyClass:(NSUInteger)i {
    MyClass *mc = [self getMyClass];
    NSLog(@"(%@) this is MyClass: %@", @(i), mc);
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    @autoreleasepool {
        for (int i = 0; i < 10; i++) {
            [self logMyClass:i];
        }
        NSLog(@"end");
    }
    NSLog(@"outside pool");
}

Pay attention to the line marked with // ATTENTION TO THIS LINE.

I could replace that line with 3 flavors:

return weakShared (__weak)
return tmpHolder (__strong)
return tmpHolder with __autoreleasing added to the tmpHolder variable indicated above.

The output of each of the above cases are:

1.

(0) this is MyClass: <MyClass: 0x600000020490>
MyClass dealloc: <MyClass: 0x600000020490>
(1) this is MyClass: <MyClass: 0x600000024270>
MyClass dealloc: <MyClass: 0x600000024270>
(2) this is MyClass: <MyClass: 0x600000024270>
MyClass dealloc: <MyClass: 0x600000024270>
end
outside pool

2.

(0) this is MyClass: <MyClass: 0x600000010570>
(1) this is MyClass: <MyClass: 0x600000010530>
MyClass dealloc: <MyClass: 0x600000010530>
(2) this is MyClass: <MyClass: 0x600000010530>
MyClass dealloc: <MyClass: 0x600000010530>
end
MyClass dealloc: <MyClass: 0x600000010570>
outside pool

3.

(0) this is MyClass: <MyClass: 0x600000020060>
(1) this is MyClass: <MyClass: 0x600000020040>
(2) this is MyClass: <MyClass: 0x600000020030>
end
MyClass dealloc: <MyClass: 0x600000020030>
MyClass dealloc: <MyClass: 0x600000020040>
MyClass dealloc: <MyClass: 0x600000020060>
outside pool

My question: Why does case 2 behave like that? I would expect it to either autorelease my variable before returning, thus behaving like 3; or just return it without autoreleasing and behave like 1.

Note: You will need the -Os flag to reproduce the above examples.

kennytm · Accepted Answer · 2018-05-30T14:10:55.183

TL;DR:

In iteration 0 the object is placed into the autorelease pool due to lazy binding of an ARC helper function breaking return-value optimization. The rest are freed as soon as possible because the symbol has been bound.

The weak reference in case 2 is red herring. You could get the same behavior after removing the weakShared variable.

@implementation AppDelegate
-(MyClass*)getMyClass {
    MyClass* tmpHolder = [[MyClass alloc] init];
    return tmpHolder;
}
...

The Objective-C code after applying ARC looks like this:

MyClass* "-[AppDelegate getMyClass]"(AppDelegate* self, SEL _cmd) {
    MyClass* tmpHolder = [[MyClass alloc] init];
    return objc_autoreleaseReturnValue(tmpHolder);
//         ~~~~~~~~~~~~~~~~~~~~~~~~~~~
}

Unlike the pre-ARC -autorelease method, the objc_autoreleaseReturnValue() function will not move the object directly into the autorelease pool. It will check the caller's assembly instructions, and if the caller is going to immediately "-retain" the value, we will instead skip the autorelease pool and return the +1'ed object directly.

void "-[AppDelegate logMyClass:]"(AppDelegate* self, SEL _cmd, NSUInteger i) {
    MyClass* mc = objc_retainAutoreleasedReturnValue([self getMyClass]);
//                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                 
    NSNumber* ii = objc_retainAutoreleasedReturnValue([NSNumber numberWithInt:i]);
    NSLog(@"(%@) this is MyClass: %@", ii, mc);
    objc_release(ii);
    objc_release(mc);
}

Because of this behavior, in iterations 1 to 9, the objc_autoreleaseReturnValue and objc_retainAutoreleasedReturnValue methods become no-op and those MyClass instances are destroyed immediately at the end of -logMyClass:.

(There are also detailed explanation of how this return optimization works on How does objc_retainAutoreleasedReturnValue work? by Matt Galloway.)

But what happened at iteration 0?

We could read the implementation of callerAcceptsOptimizedReturn which describes how objc_autoreleaseReturnValue determines the caller will "immediately retain". In short, it will ensure the caller has the following instructions immediately after the call:

48 89 c7            movq %rax, %rdi
e8 __ __ __ __      callq <something>

where dereferencing <something> should point to

ff 25 __ __ __ __   jmpq *<symbol>

where <symbol> should be the function pointer of objc_retainAutoreleasedReturnValue. However if you run the program in a debugger and trace objc_autoreleaseReturnValue, you'll find that <symbol> is not objc_retainAutoreleasedReturnValue at the first call!

The reason is that objc_retainAutoreleasedReturnValue is a lazy symbol (__DATA,__la_symbol_ptr). This is the default behavior when linking to an external dynamic library. Before calling through <symbol>, the dynamic linker will not resolve it to the correct function pointer.

And indeed, if you disable the lazy binding behavior by adding the -bind_at_load linker flag, the code will behave the same as "case 1"

$ clang -fobjc-arc -framework Foundation -bind_at_load -Og 1.m
$ ./a.out 
2018-05-30 19:25:58.838 a.out[4923:19498647] (0) this is MyClass: <MyClass: 0x7fa392400200>
2018-05-30 19:25:58.838 a.out[4923:19498647] MyClass dealloc: <MyClass: 0x7fa392400200>
2018-05-30 19:25:58.838 a.out[4923:19498647] (1) this is MyClass: <MyClass: 0x7fa392400200>
2018-05-30 19:25:58.838 a.out[4923:19498647] MyClass dealloc: <MyClass: 0x7fa392400200>
...
2018-05-30 19:25:58.839 a.out[4923:19498647] (9) this is MyClass: <MyClass: 0x7fa392600400>
2018-05-30 19:25:58.839 a.out[4923:19498647] MyClass dealloc: <MyClass: 0x7fa392600400>
2018-05-30 19:25:58.839 a.out[4923:19498647] end
2018-05-30 19:25:58.839 a.out[4923:19498647] outside pool
$

Since this problem only happens once in the whole program lifetime, this is probably why the behavior is kept unchanged.

The LLDB script which shows the lazy loading behavior:

(lldb) target create "a.out"

(lldb) b objc_autoreleaseReturnValue
Breakpoint 1: where = libobjc.A.dylib`objc_autoreleaseReturnValue, address = 0x000000000000cc6f

(lldb) r
Process 4580 launched: '~/a.out' (x86_64)
1 location added to breakpoint 1
Process 4580 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
    frame #0: 0x00007fff4fe52d1d libobjc.A.dylib`objc_autoreleaseReturnValue
libobjc.A.dylib`objc_autoreleaseReturnValue:
->  0x7fff4fe52d1d <+0>: pushq  %rbp
    0x7fff4fe52d1e <+1>: movq   %rsp, %rbp
    0x7fff4fe52d21 <+4>: movq   0x8(%rbp), %rax
    0x7fff4fe52d25 <+8>: cmpl   $0xe8c78948, (%rax)       ; imm = 0xE8C78948 
Target 0: (a.out) stopped.

(lldb) disass
libobjc.A.dylib`objc_autoreleaseReturnValue:
->  0x7fff4fe52d1d <+0>:  pushq  %rbp
    0x7fff4fe52d1e <+1>:  movq   %rsp, %rbp
    0x7fff4fe52d21 <+4>:  movq   0x8(%rbp), %rax
    0x7fff4fe52d25 <+8>:  cmpl   $0xe8c78948, (%rax)       ; imm = 0xE8C78948 
    0x7fff4fe52d2b <+14>: jne    0x7fff4fe52d64            ; <+71>
    0x7fff4fe52d2d <+16>: movslq 0x4(%rax), %rcx
    0x7fff4fe52d31 <+20>: movzwl 0x8(%rax,%rcx), %edx
    0x7fff4fe52d36 <+25>: cmpl   $0x25ff, %edx             ; imm = 0x25FF 
    0x7fff4fe52d3c <+31>: jne    0x7fff4fe52d64            ; <+71>
    0x7fff4fe52d3e <+33>: leaq   0x8(%rax,%rcx), %rax
    0x7fff4fe52d43 <+38>: movslq 0x2(%rax), %rcx
    0x7fff4fe52d47 <+42>: movq   0x6(%rax,%rcx), %rax
    0x7fff4fe52d4c <+47>: leaq   0x14e65(%rip), %rcx       ; objc_unsafeClaimAutoreleasedReturnValue
    0x7fff4fe52d53 <+54>: cmpq   %rcx, %rax
    0x7fff4fe52d56 <+57>: je     0x7fff4fe52d6a            ; <+77>
    0x7fff4fe52d58 <+59>: leaq   -0x17ef(%rip), %rcx       ; objc_retainAutoreleasedReturnValue
    0x7fff4fe52d5f <+66>: cmpq   %rcx, %rax
    0x7fff4fe52d62 <+69>: je     0x7fff4fe52d6a            ; <+77>
    0x7fff4fe52d64 <+71>: popq   %rbp
    0x7fff4fe52d65 <+72>: jmp    0x7fff4fe52920            ; objc_autorelease
    0x7fff4fe52d6a <+77>: movq   $0x1, %gs:0x160
    0x7fff4fe52d77 <+90>: movq   %rdi, %rax
    0x7fff4fe52d7a <+93>: popq   %rbp
    0x7fff4fe52d7b <+94>: retq   

(lldb) b 0x7fff4fe52d5f
Breakpoint 2: where = libobjc.A.dylib`objc_autoreleaseReturnValue + 66, address = 0x00007fff4fe52d5f

(lldb) br del 1
1 breakpoints deleted; 0 breakpoint locations disabled.

(lldb) br com add 2
Enter your debugger command(s).  Type 'DONE' to end.
> p/x $rax 
> p/x $rcx 
> c 
> DONE 

(lldb) c
Process 4580 resuming

(lldb)  p/x $rax
(unsigned long) $0 = 0x0000000100000e7e

(lldb)  p/x $rcx
(unsigned long) $1 = 0x00007fff4fe51570

(lldb)  c
Process 4580 resuming

Command #3 'c' continued the target.
2018-05-30 19:09:38.677022+0800 a.out[4580:19476452] (0) this is MyClass: <MyClass: 0x100103850>
(lldb)  p/x $rax
(unsigned long) $2 = 0x00007fff4fe51570

(lldb)  p/x $rcx
(unsigned long) $3 = 0x00007fff4fe51570

(lldb)  c
Process 4580 resuming

Command #3 'c' continued the target.
2018-05-30 19:09:38.685472+0800 a.out[4580:19476452] (1) this is MyClass: <MyClass: 0x100200050>
2018-05-30 19:09:38.685565+0800 a.out[4580:19476452] MyClass dealloc: <MyClass: 0x100200050>

...

@ewcy In Case 1, the compiler (after optimization) generated a `objc_retainAutoreleasedReturnValue(tmpHolder)` after the `weakShared = tmpHolder;` weak-store assignment, which binds the symbol. — kennytm, May 30 '18 at 18:34

Why does returning a __strong and __autoreleasing variable yields different object lifecycle only after the first time?

1 Answers1

Why does returning a strong and autoreleasing variable yields different object lifecycle only after the first time?