Am 26.04.2017 um 23:58 schrieb Charles Srstka <[email protected]>:
> How can you say this without knowing the use case? Anyway, let me assure you > that accessing the properties of the model objects was essential to > performing the task the program needed to do. Because that's how the memory model works on any modern machine? The spinlock is actually unnecessary, as all modern machines can write a pointer atomically - the write is always atomically. The only thing that's different is that the spinlock does a memory barrier. > >>>> 0000000100000e42 callq 0x100000ec8 ## symbol stub for: >>>> _objc_retainAutoreleasedReturnValue >> >> This is where the problem occurs: It's calling >> objc_retainAutoreleasedReturnValue, when it should call objc_retain. > > What? No it shouldn’t. objc_retainAutoreleasedReturnValue is the correct call > to use here. No, it is only the right call to use if what you're getting is actually retained and autorelease - which it's not for a nonatomic property. > If the method returning the value were written using ARC, it would cause it > to skip the retain/autorelease dance and just return the +1 refcounted object. No, it would be returned with +1 refcount. But the autorelease would be skipped and the additional release at the callsite would be. > And if the method were MRC (which it is, in this case), it just does the same > thing as objc_retain. Hm, right, it would not see the objc_autoreleaseReturnValue. It would not see that in any case, as it's hidden by valueForKey: - the entire optimization only works if it's passed by one level, not if it's passed by two. This fact would actually save it here in the case of valueForKey: - but the other mentioned problems remain. > Eitherway, you end up with a +1 refcounted object of which you take ownership. > > It’s really quite nifty. You can read about it here: > > https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-retainautoreleasedreturnvalue The documentation is actually quite boring and the source code much more interesting. >>> To my mind, in an ARC world, autorelease is nothing but an unneeded >>> performance hit >> >> This is not true. There's a neat little hack which makes sure the object >> never is autoreleased when using ARC: It looks at the callsite to see if >> objc_retainAutoreleasedReturnValue is called, and if so never puts it into >> the autorelease pool. > > Wait, what? I thought you were just arguing that > objc_retainAutoreleasedReturnValue should not be used? This was in response your comment that autorelease is only a performance hit in ARC - which it is not much due to this hack. > Anyway, it’s a neat hack, but it’s imperfect. I know this because I still get > objects piling up in autorelease pools, even with ARC on. Yes, it only works for things where the last thing to do is return autoreleased. Doesn't work anymore with things like valueForKey:, which is why in this case it actually would be retained. See my correction above. > Retain the stuff you get and release it later, instead of relying on > valueForKey: or the property getter to do it for you. I actually disagree with that. With the exception of objectForKey: and objectAtIndex:, you're always guaranteed a life time as long as the autorelease pool lives. nonatomic breaks this. There's a reason nothing but firstObject is declared nonatomic in Foundation. -- Jonathan _______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
