[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ARC Cleanups
Re: ARC Cleanups
Sun, 3 Jul 2011 15:59:38 +0100
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
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.
-- Sent from my STANTEC-ZEBRA