Re: ARC and autorelease pools
On Feb 17, 2014, at 2:08 , Clark Smith Cox III clark@apple.com wrote: I didn't say take them out. I said why do they need to return an autoreleased object. Because they always have, and their semantics cannot be changed without breaking decades worth of non-ARC code. Sort of like the way GC did, where you had to have 2 versions of every framework, the GC version and the non-GC version. If you had 2 versions of every framework and the compiler enforced a no autorelease rule, then you could have what you want. However, one of the big points of ARC was to not require 2 versions of every framework, but instead provide compatibility between ARC and non-ARC code. Therefore all the old requirements for autorelease, which have been explained so well by various posters, apply. Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
Thanks to Marcel, John McCall, and Clark Smith Cox III for addressing the question I was trying to ask, apologies to others that the question was unclear. So it seems that because ARC provides compatibility between ARC and non-ARC code unlike how garbage collection worked with duplicated frameworks is part of or even the main reason we can't get rid of autorelease. My response to Roland's first reply to this thread was incorrect. I had forgotten the reason why I new that class methods like stringWithFormat return an autoreleased object. When I first learnt ARC in May last year I wrote a blog post covering my experiments of when an object stays alive and when it doesn't. I hadn't just assumed, I'd forgotten why I new. In terms of crossing boundaries I find the result of TestArc9() interesting when passing a weak pointer into a function. The last line of output from each test routine is at the end of the blog post if you want to test your understanding. http://blog.yvs.eu.com/2013/05/experimental-arc/ Kevin On 17 Feb 2014, at 08:08, Marcel Weiher marcel.wei...@gmail.com wrote: On Feb 17, 2014, at 2:08 , Clark Smith Cox III clark@apple.com wrote: I didn't say take them out. I said why do they need to return an autoreleased object. Because they always have, and their semantics cannot be changed without breaking decades worth of non-ARC code. Sort of like the way GC did, where you had to have 2 versions of every framework, the GC version and the non-GC version. If you had 2 versions of every framework and the compiler enforced a no autorelease rule, then you could have what you want. However, one of the big points of ARC was to not require 2 versions of every framework, but instead provide compatibility between ARC and non-ARC code. Therefore all the old requirements for autorelease, which have been explained so well by various posters, apply. Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
ARC and autorelease pools
I've realized that my understanding of ARC is not as good as I thought it was. So I'll be asking couple of questions. With ARC I don't understand why autorelease pools are needed anymore except for with objects passed by reference. What I mean by that is that class methods like: NSString *myString = [NSString stringWithFormat:@%@, @my string]; Why do these methods need to return an autoreleased object, why can't they behave the same as: NSString *myString = [[NSString alloc] initWithFormat:@%@, @my String]; Is the only reason for interoperability with manual retain-release code? It seems that it creates an unnecessary complication when thinking about memory management. Now I'm assuming that any method like: NSString *expandedPath = [myPath stringByExpandingTildeInPath]; returns an autoreleased string so I need to know this if I'm doing this with lots of strings and that I need to put my own autorelease pool in place, something I wouldn't have to think about if it wasn't an autoreleased object. Documentation doesn't provide any information as to which methods return an autoreleased object or not. But since I can't call autorelease myself in ARC code if I have a method like. KMImage *bigImage = [image kmImageByDoublingSize]; I'm not returning an autoreleased object so there is a difference in behaviour between the behaviour of methods in apple frameworks and the ones outside of those frameworks. I've read a couple of posts on stackoverflow in relation to ARC and autorelease, but the justification given in the answers as to why autorelease is needed is because there are methods that return autoreleased objects so we need to have a mechanism to put auto release pools in place, which I feel is a little circular. Is there something more fundamental that I'm missing beyond interoperability that means we still need autorelease pools or is it just that? Kevin ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On 16 Feb, 2014, at 9:27 pm, Kevin Meaney k...@yvs.eu.com wrote: I've realized that my understanding of ARC is not as good as I thought it was. So I'll be asking couple of questions. With ARC I don't understand why autorelease pools are needed anymore except for with objects passed by reference. What I mean by that is that class methods like: NSString *myString = [NSString stringWithFormat:@%@, @my string]; Why do these methods need to return an autoreleased object, why can't they behave the same as: NSString *myString = [[NSString alloc] initWithFormat:@%@, @my String]; Where did you determine that the first of those returns an autoreleased object and does not, in fact, behave as the second? Where is it documented that [ NSString stringWithFormat:.. ] under ARC returns an autoreleased object? Is the only reason for interoperability with manual retain-release code? perhaps - the whole document about ARC is here http://clang.llvm.org/docs/AutomaticReferenceCounting.html, it only says that autorelease pools can exist and that the syntax for them has been tightened up into a real scope. It mentioned a couple of conditions in which it may use them and introduces some qualifiers which force objects into them but nowhere do I see anything which says they are definitely used in any given situation. There are several places it says you may not assume that an object is in an autorelease pool. It seems that it creates an unnecessary complication when thinking about memory management. Now I'm assuming that any method like: NSString *expandedPath = [myPath stringByExpandingTildeInPath]; returns an autoreleased string so I need to know this if I'm doing this with lots of strings and that I need to put my own autorelease pool in place, something I wouldn't have to think about if it wasn't an autoreleased object. Documentation doesn't provide any information as to which methods return an autoreleased object or not. before ARC it was pretty much a given a method like that returned an autoreleased object, now it may or may not return one, so you're no worse off than you were before and are possibly better off. The usual advice is to do the simplest thing and if you have memory issues, go hunt them down with Instruments. And also assume that Debug and Release will do entirely different things. But since I can't call autorelease myself in ARC code if I have a method like. KMImage *bigImage = [image kmImageByDoublingSize]; I'm not returning an autoreleased object so there is a difference in behaviour between the behaviour of methods in apple frameworks and the ones outside of those frameworks. I don't think you can know whether or not you are returning an autoreleased object in that case. I'm assuming that method does the obvious thing from the name, creates a double-sized image and returns it. Whether ARC retains it across the return for you or puts it on an autorelease pool, you don't know, how ARC chooses to keep the object valid across the return boundary is not defined by the ARC spec. It might be either but you shouldn't have to care. I've read a couple of posts on stackoverflow StackOverflow has a reasonably high noise to signal ratio. I'm pleased you posted here because Greg Parker is going to correct everything I wrote and explain it properly. The usual advice I think still stands. If you create lots of temporary objects in a loop, check for memory issues and put an autorelease pool in there if you have issues. If you don't have issues, let the compiler do the job for you. Kevin ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 7:27 AM, Kevin Meaney k...@yvs.eu.com wrote: Why do these methods need to return an autoreleased object, why can't they behave the same as: NSString *myString = [[NSString alloc] initWithFormat:@%@, @my String]; Is the only reason for interoperability with manual retain-release code? Foundation, along with the other system frameworks, is not written in ARC. It's written in manual retain-release. If/when Apple eventually converts the frameworks to ARC, they will have to remove the 32-bit versions of the binaries, since ARC is only compatible with the 64-bit runtime. This will break backward compatibility with all 32-bit apps, including all Carbon apps. I don't know about you, but I'm perfectly happy if Apple decides to take their time getting around to that. Charles ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 5:27 AM, Kevin Meaney k...@yvs.eu.com wrote: Is the only reason for interoperability with manual retain-release code? For backward compatibility. Nearly every piece of existing Cocoa code uses these methods, so there's no way they could take them out. It seems that it creates an unnecessary complication when thinking about memory management. Now I'm assuming that any method like: NSString *expandedPath = [myPath stringByExpandingTildeInPath]; returns an autoreleased string so I need to know this if I'm doing this with lots of strings and that I need to put my own autorelease pool in place, something I wouldn't have to think about if it wasn't an autoreleased object. You don't just need to consider whether methods you call return autoreleased objects (and as Roland pointed out, it's not always clear whether a returned object really has been autoreleased or not.) You also need to consider whether the method you called caused objects to be autoreleased as part of the work it did. That is, you might call [[FooController alloc] init], which doesn't return an autoreleased object, but perhaps the -init method did a bunch of work that involved autoreleasing objects. In that case your call to that method would still add a bunch of objects to the autorelease pool. You can't tell by looking at the declaration. In practice, I add @autoreleasepool blocks by considering whether I'm writing a loop that will have a lot of iterations and whose body involves method calls that are likely to allocate memory. Then I also look at memory usage over time in the Instruments app and watch for spikes, and look for issues (on iOS) where the app triggers a low-memory notification during some activity. Likely to allocate memory is weaselly, I know. It's an educated guess. But you don't have to guess perfectly. An unnecessary @autoreleasepool is unlikely to add noticeable (unless you go overboard with them), and if you leave one out where you need one, you'll probably notice during testing. It's part of the kind of memory/performance tuning you'll be doing anyway later in development. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On 16 Feb 2014, at 17:06, Jens Alfke j...@mooseyard.com wrote: On Feb 16, 2014, at 5:27 AM, Kevin Meaney k...@yvs.eu.com wrote: Is the only reason for interoperability with manual retain-release code? For backward compatibility. Nearly every piece of existing Cocoa code uses these methods, so there's no way they could take them out. I didn't say take them out. I said why do they need to return an autoreleased object. Why can't they just return an object like alloc init... does. I think Roland's main point is to ask do they return an autoreleased object. I foolishly assumed they did because a modified version of autorelease was kept with the transition to ARC and my most common experience of dealing with autoreleased objects was via the behaviour of the class methods that create objects. So yes a foolish assumption on my behalf. It seems that it creates an unnecessary complication when thinking about memory management. Now I'm assuming that any method like: NSString *expandedPath = [myPath stringByExpandingTildeInPath]; returns an autoreleased string so I need to know this if I'm doing this with lots of strings and that I need to put my own autorelease pool in place, something I wouldn't have to think about if it wasn't an autoreleased object. You don't just need to consider whether methods you call return autoreleased objects (and as Roland pointed out, it's not always clear whether a returned object really has been autoreleased or not.) You also need to consider whether the method you called caused objects to be autoreleased as part of the work it did. You're missing the question I was trying to ask. Why is autorelease needed at all? If we don't have autorelease then it is precisely clear whether a returned object is autoreleased or not. Something we don't even have to consider. We don't have to worry about whether further down the stack autoreleased objects have been created or not and that in certain situations up the stack we need to add in a autorelease pool. I've read through some of the clang documentation Roland referred to, much of it over my head. I did note that there was some discussion over making sure that objects remain alive over the return boundary and in some cases autorelease was used for this purpose. But I'm still failing to grasp why, if autorelease is being used in some cases for making sure an object remains alive over a return boundary that means there are other ways of dealing with making sure an object remains alive over the return boundary, do we need autorelease? I just feel like I'm missing something. The people at Apple or Clang have decided that keeping autorelease is necessary and I'm struggling to understand why when it seems to me it adds unnecessary complexity. Not major but just another thing that can go wrong if you dont think about it, and so you have to think about it and that takes mental resources away from the job at hand. Kevin ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 10:22 AM, Kevin Meaney k...@yvs.eu.com wrote: I didn't say take them out. I said why do they need to return an autoreleased object. Why can't they just return an object like alloc init... does. Because if they returned an object that wasn't autoreleased (i.e. that the caller needs to release), non-ARC code that called the method would leak the returned object. These methods have been around for a long time and their semantics can't be changed just because ARC now exists, at least not until some hypothetical future OS release where ARC becomes mandatory. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 10:22 AM, Kevin Meaney k...@yvs.eu.com wrote: You're missing the question I was trying to ask. Why is autorelease needed at all? It's needed when a method creates an object [or otherwise gets an object with a reference that needs to be released] and has to return that object, but the caller isn't aware that the reference needs to be released. The method can call -autorelease on that object, which schedules a pending release in the future, balancing the ref-counting. You could argue that if ARC were mandatory [which it isn't, remember] autorelease wouldn't be necessary because the method above can be declared as returning a strong reference, so the caller will know to release it. Unfortunately it isn't that simple, because there can be multiple implementations of a method. For example, a class might implement a -bgColor method that returns an NSColor stored in an instance variable; so the return value doesn't need to be released. But a subclass might override -bgColor to allocate and return a new NSColor instance. Now the caller _does_ need to release it, but the caller doesn't know that because it has no idea which implementation of -bgColor actually got called. The only way to resolve this without autorelease would be to enforce that _all_ methods that return objects have to return a retained reference for the caller to release. This would end up adding a huge number of retain/release calls, which I'm pretty sure would affect performance. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
And would be just like every other manual reference-counting scheme, with all of the additional code they entail, and the higher liklihood of bugs, and so on... On Feb 16, 2014, at 2:13 PM, Jens Alfke j...@mooseyard.com wrote: The only way to resolve this without autorelease would be to enforce that _all_ methods that return objects have to return a retained reference for the caller to release. This would end up adding a huge number of retain/release calls, which I'm pretty sure would affect performance. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 1:03 PM, Jens Alfke j...@mooseyard.com wrote: On Feb 16, 2014, at 10:22 AM, Kevin Meaney k...@yvs.eu.com wrote: I didn't say take them out. I said why do they need to return an autoreleased object. Why can't they just return an object like alloc init... does. Because if they returned an object that wasn't autoreleased (i.e. that the caller needs to release), non-ARC code that called the method would leak the returned object. These methods have been around for a long time and their semantics can't be changed just because ARC now exists, at least not until some hypothetical future OS release where ARC becomes mandatory. Also, the ARC model doesn’t support a mandatory cut-over like that. Returning +0 is essentially part of the calling convention: if you know exactly what you’re calling, and you know exactly what’s calling it, maybe then you could automatically change it. In Objective-C both of those conditions are impossible. John. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 10:22, Kevin Meaney k...@yvs.eu.com wrote: On 16 Feb 2014, at 17:06, Jens Alfke j...@mooseyard.com wrote: On Feb 16, 2014, at 5:27 AM, Kevin Meaney k...@yvs.eu.com wrote: Is the only reason for interoperability with manual retain-release code? For backward compatibility. Nearly every piece of existing Cocoa code uses these methods, so there's no way they could take them out. I didn't say take them out. I said why do they need to return an autoreleased object. Because they always have, and their semantics cannot be changed without breaking decades worth of non-ARC code. Why can't they just return an object like alloc init... does. It can, if both the implementation and the caller are ARC I think Roland's main point is to ask do they return an autoreleased object. I foolishly assumed they did because a modified version of autorelease was kept with the transition to ARC and my most common experience of dealing with autoreleased objects was via the behaviour of the class methods that create objects. So yes a foolish assumption on my behalf. It seems that it creates an unnecessary complication when thinking about memory management. Now I'm assuming that any method like: NSString *expandedPath = [myPath stringByExpandingTildeInPath]; returns an autoreleased string so I need to know this if I'm doing this with lots of strings and that I need to put my own autorelease pool in place, something I wouldn't have to think about if it wasn't an autoreleased object. You don't just need to consider whether methods you call return autoreleased objects (and as Roland pointed out, it's not always clear whether a returned object really has been autoreleased or not.) You also need to consider whether the method you called caused objects to be autoreleased as part of the work it did. You're missing the question I was trying to ask. Why is autorelease needed at all? If we don't have autorelease then it is precisely clear whether a returned object is autoreleased or not. Something we don't even have to consider. We don't have to worry about whether further down the stack autoreleased objects have been created or not and that in certain situations up the stack we need to add in a autorelease pool. I've read through some of the clang documentation Roland referred to, much of it over my head. I did note that there was some discussion over making sure that objects remain alive over the return boundary and in some cases autorelease was used for this purpose. But I'm still failing to grasp why, if autorelease is being used in some cases for making sure an object remains alive over a return boundary that means there are other ways of dealing with making sure an object remains alive over the return boundary, do we need autorelease? If both sides of the boundary are ARC, and the calling code immediately retains the returned value (as is usually the case), then the autorelease can be skipped (and actually is at runtime; the runtime is smart enough to actually inspect the stack to see whether or not the autorelease is necessary, and if it isnt, it actually skips the autorelease and the following retain). I just feel like I'm missing something. The people at Apple or Clang have decided that keeping autorelease is necessary and I'm struggling to understand why when it seems to me it adds unnecessary complexity. Not major but just another thing that can go wrong if you dont think about it, and so you have to think about it and that takes mental resources away from the job at hand. Keeping autorelease is necessary because without it, there would be no way of maintaining the memory management contract across both ARC and non-ARC code. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Arc and autorelease
Without Arc, this: NSString *s = [ [ NSString alloc ] initWithFormat: ...]; [ someCollection addObject: s ]; [ s release ]; is clearly more efficient (because not using autoreleasepools) than: NSString *s = [ NSString stringWithFormat: ...]; [ someCollection addObject: s ]; But what about Arc? Is the compiler clever enough to make both versions equally efficient? Or should one still avoid using the convenience method stringWithFormat: ? Kind regards, Gerriet. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Arc and autorelease
On May 24, 2012, at 3:14 AM, Gerriet M. Denkmann wrote: Without Arc, this: NSString *s = [ [ NSString alloc ] initWithFormat: ...]; [ someCollection addObject: s ]; [ s release ]; is clearly more efficient (because not using autoreleasepools) than: NSString *s = [ NSString stringWithFormat: ...]; [ someCollection addObject: s ]; But what about Arc? Is the compiler clever enough to make both versions equally efficient? Maybe. You can't know if the NSString implementation was itself compiled with ARC. If it was, then there is a *possible* optimization that can avoid the autorelease+retain. However, you can't rely on this. Or should one still avoid using the convenience method stringWithFormat: ? Are you programming for iOS? The recommendation for that is still to avoid autoreleased objects so as to keep the high-water mark of memory usage down. For Mac OS X it's never been that big a concern except for code in a loop or the like. Regards, Ken ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Arc and autorelease
On May 24, 2012, at 1:14 AM, Gerriet M. Denkmann wrote: Without Arc, this: NSString *s = [ [ NSString alloc ] initWithFormat: ...]; [ someCollection addObject: s ]; [ s release ]; is clearly more efficient (because not using autoreleasepools) than: NSString *s = [ NSString stringWithFormat: ...]; [ someCollection addObject: s ]; But what about Arc? Is the compiler clever enough to make both versions equally efficient? Or should one still avoid using the convenience method stringWithFormat: ? As a rule, ARC tries to keep objects out of the local autorelease pool, and can usually succeed at that even when working with code that is not itself compiled under ARC. I would use whichever method makes sense to you and only worry about high watermark issues if you discover a performance issue. -- David Duncan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
