[swift-dev] Shrinking the heap object header
rjmccall at apple.com
Fri Jan 15 13:51:04 CST 2016
> On Jan 15, 2016, at 10:58 AM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
> Swift heap object headers are fairly large—16 bytes on 64-bit, and 12 bytes on 32-bit. Into this space we pack:
> - the 'isa' pointer for the object, pointing to its heap metadata/class object,
> - the strong and unowned reference counts,
> - 'pinned' and 'deallocating' flags.
> We've also discussed taking a flag bit for 'not refcounted' objects, such as statically-allocated globals and/or stack promotions that need to be ABI compatible with heap objects, and potentially one for thread-local objects, to avoid barriers when refcounting objects we dynamically know are not referenced from multiple threads. We should consider whether we can reduce the header size. Two ideas come to mind:
> Dropping the unowned reference count
> If we adopt a sufficiently fast implementation for normal weak references, such as the activity count implementation suggested by Kevin and Mike, the unowned reference count might not be worth the expense. If we dropped it, that would be enough to bring the 32-bit object header down to 8 bytes. The tradeoff would be that unowned references become fatter, like weak references would, which might complicate our plans to eventually allow unowned to transparently become unowned(unsafe) in unchecked builds.
Unless I’m misunderstanding something, the activity count implementation doesn’t actually change anything about the need to register the existence of the weak/unowned reference with the object.
We could compact the two reference counts into a single 32-bit header; that would help a lot on 32-bit targets. However, doing so would shrink both reference counts to the point that leaking on overflow would become unacceptable; we would definitely need some ability to spill over into a side table.
> Non-pointer isa for 64-bit platforms
> Neither x86-64 nor ARM64 populates the full 64 bits of address space—contemporary x86-64 uses only 48 bits (sign-extended, so effectively 47 bits for userspace), and Apple ARM64 platforms use fewer bits, the exact number dependent on OS version. If we were willing to drop the unowned refcount, and say that "64Ki-retains ought to be enough for anyone", overflowing the retain count into the "not refcounted" bit to leak overly-retained objects, we could use a layout similar to this to pack the remaining information into 8 bytes:
> bits meaning
> ----- -------
> 63 not refcounted
> 47…62 strong refcount
> 03…46 metadata pointer
> 02 (reserved)
> 01 deallocating
> 00 pinned
> There are of course some costs and complications. For classes, we look up vtable entries and resilient ivar offsets through the isa pointer, and masking the isa costs an extra instruction per object, though that can at least be shared for multiple method calls on the same object since we assume objects don't change class (at least not in ways that would change Swift method implementation or ivar layout). We do already pay this cost on Apple platforms for NSObject subclasses. More interestingly, Objective-C already uses non-pointer isa on ARM64, but not on x86-64. I'm not sure how flexible the ObjC implementation is here—Could Swift use non-pointer isas on platforms where ObjC doesn't? Could it ascribe different meanings to the bits from ObjC's?
> swift-dev mailing list
> swift-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev