Re: Why does ARC retain method arguments even with full optimization?
Re: Why does ARC retain method arguments even with full optimization?
- Subject: Re: Why does ARC retain method arguments even with full optimization?
- From: Wade Tregaskis <email@hidden>
- Date: Sat, 05 Nov 2011 10:50:21 -0700
> The way I understand it with ARC, though, is that it can peek at the stack to see what will happen to a pointer after it’s returned, and cut out some of the unnecessary message sends, so while it’s actually generating something like this:
>
> - (Foo *)foo {
> return objc_retainAutoreleaseReturnValue(fooIvar);
> }
>
> - (void)bar {
> Foo *foo = objc_retainAutoreleasedReturnValue([self foo]);
> [self doSomethingElse];
> [foo bar];
> objc_release(foo);
> }
>
> in practice, it’s effectively doing something equivalent to this:
>
> - (Foo *)foo {
> return [fooIvar retain];
> }
>
> - (void)bar {
> Foo *foo = [self foo]; // -autorelease and -retain cancel each other out here, so they’re both eliminated at runtime
> [self doSomethingElse];
> [foo bar];
> [foo release];
> }
>
> The messages actually sent to foo are retain and release, a total of two message sends; plus, the autorelease pool doesn’t get involved. That’s a win if you ask me.
Note that (so far as Mac OS X is concerned - I don't know about iOS) this only happens with the 64-bit runtime on Intel, on Lion. Previous runtimes don't even have this optimisation, and there's somewhat surprisingly no 32-bit implementation of the critical callerAcceptsFastAutorelease().
I'm also curious how this would fare in the presence of instruction reordering by the compiler. callerAcceptsFastAutorelease() as implemented today relies on the very next instruction - i.e. the destination of the tail-call-optimised return address, being a jump to objc_retainAutoreleasedReturnValue(). Strictly speaking there's no reason why that has to be the case - the compiler could choose to interleave other, relatively unrelated instructions in there.
That said, in some sense this is all bandaids on bandaids, and this could all be moot in a future runtime. If the runtime decided that overriding retain/release were verboten, it could more or less turn retain/release into a couple of inlined instructions each. At least, so a cursory analysis suggests. That wouldn't by itself get rid of this stack peeking business, but if compatibility with non-ARC code [and runtimes before a certain date] were dropped, then that could go too._______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden