<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 1:08 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 11:51 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 10:58 AM, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Swift heap object headers are fairly large—16 bytes on 64-bit, and 12 bytes on 32-bit. Into this space we pack:<div class=""><br class=""></div><div class="">- the 'isa' pointer for the object, pointing to its heap metadata/class object,</div><div class="">- the strong and unowned reference counts,</div><div class="">- 'pinned' and 'deallocating' flags.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><b class="">Dropping the unowned reference count</b></div><div class=""><b class=""><br class=""></b></div><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div>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.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote><br class=""></div><div class="">I probably misunderstood too. If that's the case, we could still probably allocate more bits to the strong refcount than to the unowned one, since it's probably more acceptable to spill into a side table for weak references more often than for strong ones.</div></div></div></blockquote><div><br class=""></div></div>Agreed. I just mean that it probably still shrinks the strong reference count down to a point (~20 bits?) that leaking isn’t obviously acceptable.<div class=""><br class=""></div><div class="">John.</div></body></html>