Re: ARC Cleanups

[David Chisnall]

On 3 Jul 2011, at 15:43, Stefan Bidi wrote:

> I'm not currently making use of it but CoreFoundation seems to use 
> zones/allocators quite extensively.  Every Create and Copy function takes a 
> CFAllocatorRef.


Note that this kind of usage doesn't require being able to get the zone for the 
object, although freeing it correctly does require being able to get the free() 
function from the CFAllocatorRef().

There are three possible ways of getting the zone for an object:

1) Store its zone in an ivar, set by allocWithZone:.  This requires every class 
that is likely to care about its zone to add an ivar for storing it.  Several 
GNUstep classes do this, which means that they actually store the zone twice.

2) Store its zone in the pseudo-ivar in the object header.

3) Walk the list of zones and asking each one if it allocated the object.

On OS X, they use a combination of 1 and 3, although 3 is easier because their 
malloc implementation understands zones at the low level (both NSZone and 
CFAllocatorRef are built on top of malloc_zone_t).  GNUstep, in contrast, 
stores an extra pointer for every allocation, even when it's not needed.  This, 
breaks if an object is allocated with class_createInstance(), which is not 
zone-aware (although in trunk will now allocate space for a reference count).

I'm not advocating removing this pointer, but at the moment it's private and 
only accessed in NSObject.m.  With ARC, the runtime needs to be able to find 
the reference count for the fast path, so this becomes part of the interface 
between the runtime and Foundation, and so has to be stable.  If we keep the 
order refcount, zone, isa, then we can't remove the zone pointer without 
breaking the ABI.  If we change the order to zone, refcount, isa, then the 
interface is just refcount, isa, and we can delete the zone in the future  if 
we want, or keep it if it makes sense.

David

-- Sent from my STANTEC-ZEBRA