[swift-dev] [Discussion] New refcount representation

[Greg Parker]

> On Mar 16, 2016, at 2:23 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Mar 15, 2016, at 11:59 PM, Greg Parker via swift-dev <swift-dev at swift.org> wrote:
>> I am considering a new representation for Swift refcounts and other per-object data. This is an outline of the scheme. Comments and suggestions welcome.
> 
> There are a lot of really good ideas.  I would like to see some quasi-specifics about the proposed bit layout of the inline reference count, however.  You said that there would still be an inline unowned reference count; is that now tracked independently of the weak reference count?  And do we still have an efficient fast path for testing uniquely-reference-or-pinned?

I have been imagining something like this:

32-bit object without side allocation:
   (MSB)
       2 bits  00 (ordinary) or 11 (strong refcount is constant)
      20 bits  strong refcount
       1 bit   is deallocating
       1 bit   is pinned
       8 bits  unowned refcount and any other flags
   (LSB)

64-bit object without side allocation:
   (MSB)
       2 bits  00 (ordinary) or 11 (strong refcount is constant)
      28 bits  strong refcount
       1 bit   is deallocating
       1 bit   is pinned
      32 bits  unowned refcount and any other flags
   (LSB)

Object with side allocation:
   (MSB)
       2 bits  10
   ptr-2 bits  side allocation >> 2
   (LSB)

Side allocation:
     ptr bits  object
      30 bits  strong refcount
       1 bit   is deallocating
       1 bit   is pinned
      32 bits  unowned refcount
      32 bits  weak refcount
     ptr bits  associated reference table
     ptr bits  extension ivars
               ...etc

The uniquely-referenced-or-pinned check can use the same 1-bit rotate trick on 64-bit. On 32-bit it needs an extra shift first to throw away the unowned refcount and other flags. (We might be able to eliminate that shift if there are no other flags, by rearranging the fields and assuming that the unowned refcount will be zero for a uniquely-referenced object.)

On both architectures a constant-refcount object will appear to be multiply referenced. That sounds like the correct behavior for read-only objects (you wouldn't want to modify them in place anyway) but perhaps not the correct behavior for stack-allocated objects. 


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler