[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.
-Joe
-------------- 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