[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ARC Cleanups
From: |
David Chisnall |
Subject: |
Re: ARC Cleanups |
Date: |
Mon, 4 Jul 2011 12:23:42 +0100 |
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