Re: ARC & Autorelease pool question

[David Chisnall]

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.

David