[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ARC & Autorelease pool question

From: David Chisnall
Subject: Re: ARC & Autorelease pool question
Date: Mon, 13 May 2019 17:44:04 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 13/05/2019 07:59, Andreas Fink wrote:
My question is simple: What is the correct way to compile gnustep-base with ARC 
so it wont even use autorelease pools at all. Or is this not possible?

This is not possible for two reasons:

1. No one has migrated -base to use ARC. I had a brief try, but a lot of the code in -base doesn't automatically work with the ARC migration tool and I wasn't sufficiently motivated to go and make a load of changes that would make merging changes from the mainline version difficult.

2. ARC does not preclude using autorelease pools, though it does make them cheaper.

ARC adds a mechanism where you can, effectively, pop the top item from an autorelease pool if (and only if) the caller and callee were both compiled with ARC and agree to this protocol. The callee will do this automatically if compiled with ARC. The caller must take ownership of the reference and ensure that no other in-scope manipulations of the reference count cause the object to be deallocated.

Note that this is absolutely not the same as never using anautorelease pool. Any function or method that does not either explicitly mark its return value as __strong or use one of the method families that implies strong (such as +new*, +alloc*) will return an autoreleased object.

If you are returning an object multiple frames up the stack then using an autorelease pool can be cheaper. Similarly, if you do other things that may decrement the object's reference count, then it may be cheaper to leave it in the autorelease pool than do a load of reference count manipulation.

> I now populated my code with massive amounts of @autorelease { ... } in the meantime but I consider this ugly.

This is exactly what the @autoreleasepool is for. One of the design goals for ARC was deterministic memory consumption, which means placing deallocation points in the user's control. If you don't want to do this, accept having a load of objects in autorelease pools.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]