> On Apr 26, 2017, at 6:27 PM, Jonathan Schleifer <[email protected]> > wrote: > > 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.
The lock is necessary because atomic properties promise that concurrent reads and writes will yield consistent values without crashing. That is the primary semantic guarantee of atomic properties. If you believe that that guarantee is pointless, you are arguing for the use of nonatomic properties. Whether or not a property getter autoreleases its return value is unrelated to atomic properties except inasmuch as an atomic property getter must retain its current value in order to satisfy its semantic guarantee, and that retain has to be balanced somehow. When an atomic property can satisfy its semantic guarantee without retaining — for example, if it has a guarantee that the value is retained elsewhere, e.g. as an __unsafe_unretained property does — then the getter does not need to autorelease the result. John. > >> >>>>> 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/rjmccall%40apple.com > > This email sent to [email protected] _______________________________________________ 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]
