> On Apr 26, 2017, at 5:27 PM, Jonathan Schleifer <[email protected]> > wrote: > > Am 26.04.2017 um 23:58 schrieb Charles Srstka <[email protected] > <mailto:[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.
This was in response to your claim that the code probably didn’t actually need to access the object’s properties. >>>>> 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. It’s the right call, because the compiler can’t *know* whether what it’s getting is retained and autoreleased, because it doesn’t have the source code for valueForKey:. Nevertheless, it does the correct thing in either case. In any case, it’s what the compiler inserts, so if it *were* the wrong call to use, that would be something you’d need to take up with the compiler team. >> 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. That’s more or less exactly what I said. >> 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 >> >> <https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-retainautoreleasedreturnvalue> > > The documentation is actually quite boring and the source code much more > interesting. But the documentation is much clearer and more succinct, making it easier to avoid misunderstandings. >>>> 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. Autorelease is an unnecessary performance hit in ARC. The hack attempts to cut down on the number of autoreleases, to reduce the performance hit. It does this because autorelease is an unnecessary performance hit in ARC. >> 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. I provided an example with a direct property access and no usage of valueForKey:, in which autorelease nonetheless still showed up in Instruments. >> 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. Could you please provide a link to where this guarantee is stated in the documentation? Charles
_______________________________________________ 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]
