Re: Interesting difference in memory management of MacOS Foundation and GNUstep

[Greg Parker]

On Feb 17, 2014, at 5:39 AM, David Chisnall <David.Chisnall@cl.cam.ac.uk> wrote:
> On 17 Feb 2014, at 13:33, Mathias Bauer <mathias_bauer@gmx.net> wrote:
>> in case somebody else is also interested in this: it seems that Apple's 
>> runtime "protects" the developer by ignoring changes to the retain count as 
>> soon as the object entered its deallocate method. Wrong decision, IMHO.

The model is that an object that has entered -dealloc is dying, and no amount 
of retaining will preserve it.

Balanced retain/release after -dealloc has started is correct, and does not 
cause -dealloc to be re-entered. (This is important because it's common for 
complicated -dealloc methods to cause the object to be innocently retained and 
released as a side-effect of doing something else.)

Unbalanced retain/release after -dealloc has started is an error, and the 
runtime will complain about it on some platforms. Such complaints are not 
universal for binary compatibility and performance reasons.


> It is likely that this is a side effect of weak reference support.  Classes 
> must notify the runtime when they start deallocation now, so that concurrent 
> loads of weak references abort the deallocation.  Apple's implementation 
> stores objects' refcounts in a map table, so once the object has entered 
> deallocation it's likely just a separate path.  I wouldn't be surprised if 
> this is not an active decision at all, however it does make adding cycle 
> detection to ARC easier...

Weak reference support didn't change retain counting. Instead, the behavior of 
weak references was designed to match the behavior of retain counts during 
-dealloc. Once you begin -dealloc you are irrevocably dying. Weak references to 
you are cleared and -retain won't keep you alive.


-- 
Greg Parker     gparker@apple.com     Runtime Wrangler