[swift-dev] Shrinking the heap object header

Joe Groff jgroff at apple.com
Mon Jan 18 15:24:10 CST 2016

> On Jan 15, 2016, at 4:36 PM, Greg Parker <gparker at apple.com> wrote:
>> On Jan 15, 2016, at 4:21 PM, Greg Parker via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> On Jan 15, 2016, at 10:58 AM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> 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
>> Note that the memory analysis folks really want a few bits reserved with a constant value. That improves their reliability when distinguishing real objects from non-object memory that happens to have an isa-like field in front. ObjC currently gives them 6 bits on all architectures.
> To clarify: Analysis tools like `heap` and `leaks` need to distinguish real objects from other heap allocations. The false positive rate is tolerable if the isa field is a raw pointer. (As long as some other code like libobjc itself deliberately disguises some of its own data structures that would otherwise look like false positives.)
> Non-pointer isa greatly increases the false positive rate. There is too much non-object data that happens to match some real class pointer when only the class bits can be examined. Adding some constant non-zero bits brings it back down again. 

The tools team is probably going to hate us as soon as we start using non-zero address points for objects too. We might need a different approach for Swift to reliably recognize our heap object allocations.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160118/9370527f/attachment.html>

More information about the swift-dev mailing list