> 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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
