> On Mar 16, 2016, at 2:23 PM, John McCall <[email protected]> wrote:
>
>> On Mar 15, 2016, at 11:59 PM, Greg Parker via swift-dev
>> <[email protected]> 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 [email protected] Runtime Wrangler
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
