> On Mar 15, 2016, at 11:59 PM, Greg Parker via swift-dev <swift-dev@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. > > Advantages: > * 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. > > Disadvantages: > * 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: 1% QuickSort 2% InsertionSort 4% Array2D 5% HeapSort -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
