Re: ARC Cleanups

[David Chisnall]

On 4 Jul 2011, at 12:05, Nicola Pero wrote:

>> 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.
> 
> Yes, it makes sense, and it would be good to have a simple and stable ABI. :-)
> 
> Btw, if we're changing everything, I wonder if we shouldn't even make these 
> normal
> instance variables ... then, the ABI for the runtime would be really simple 
> ... the
> first instance variable would be the class ('isa'), and the second one would 
> be the
> retain count.  The third one would be the zone, and the runtime can ignore 
> that.
> 
> I can think of a number of problems and complications with this, so I'm not 
> sure it would
> be a good idea, but it's worth considering. ;-)

I did wonder about this.  It's trivial to do if everything is compiled with the 
non-fragile ABI, but it's harder to do in the general case.  It's pretty widely 
documented that, if you are creating a new root class, then you need to add the 
isa pointer as the first ivar.  

In fact, I'd like to move in the opposite direction.  Direct access to the isa 
pointer is now deprecated and is strongly discouraged.  I talked to Steve 
Naroff a bit about this before he retired, and he agreed that it was one of the 
mistakes he and Brad Cox made when designing Objective-C: the isa pointer 
should have been an implementation detail of the runtime, not something that 
should be exposed directly.  

With the non-fragile ABI, it's actually quite simple to make the runtime 
implicitly reserve space for an isa pointer, and it would be similarly easy to 
add a reference count ivar as well.  Unfortunately, that would break 
compatibility with all code compiled for the fragile ABI with clang and with 
GCC, which I'm hesitant to do.

Having the reference count in front of the object also means that it's easy to 
remove it in GC mode.  In the 1.6 release of the runtime, I plan on 
implementing an ARC-on-GC mode, implementing the ARC read and write barriers in 
terms of the GC ones, so that we can mix ARC and GC compilation units, or ARC 
and manual reference counting.   It would be nice to just compile frameworks 
and applications in ARC mode and flip a switch in the runtime to enable GC 
mode, without needing any recompilation.  

Since ARC is now the default development mode for XCode, it's where I'm 
concentrating my efforts.  It's a shame they didn't add a cycle detector - I'll 
probably revisit GCKit at some point and make it into an opt-in cycle detector 
for individual classes - but it dramatically improves the Objective-C memory 
model.  Being able to store weak references on the stack is also pretty 
interesting.

David

-- Send from my Jacquard Loom