[swift-dev] [Discussion] New refcount representation
gparker at apple.com
Thu Mar 17 01:29:15 CDT 2016
> 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.
> Today, each object stores 64-bits of refcounts and flags after the isa field.
> In this new system, each object would store a pointer-size field after the isa field. This field would have two cases: it could store refcounts and flags, or it could store a pointer to a side allocation that would store refcounts and flags and additional per-object data.
> * Saves 4 bytes per object on 32-bit for most objects.
> * Improves refcount overflow and underflow detection.
> * Might allow an inlineable retain/release fast path in the future.
> * Allows a new weak reference implementation that doesn't need to keep entire dead objects alive.
> * Allows inexpensive per-object storage for future features like associated references or class extensions with instance variables.
> * Basic RR operations might be slower on x86_64. This needs to be measured. ARM architectures are probably unchanged.
I wrote a performance mockup of the fast path. It simply checks the MSB in the appropriate places in RefCount.h but does not actually implement any side allocation. I ran it on some RR-heavy benchmarks (QuickSort, InsertionSort, HeapSort, Array2D) on x86_64 and arm64.
arm64 is in fact approximately unchanged. Any difference either way is much less than 1%.
x86_64 is measurably slower:
Greg Parker gparker at apple.com Runtime Wrangler
More information about the swift-dev