[swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

[Joe Groff]

> On Mar 8, 2016, at 1:48 PM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
> 
>> 
>> On Mar 8, 2016, at 1:04 PM, John McCall via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>>> On Mar 8, 2016, at 2:24 AM, Bryan Chan <bryan.chan at ca.ibm.com <mailto:bryan.chan at ca.ibm.com>> wrote:
>>> John McCall via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote on 2016-03-01 06:23:24 PM:
>>> 
>>>>> On Mar 1, 2016, at 3:05 PM, Greg Parker via swift-dev <swift-
>>>> dev at swift.org <mailto:dev at swift.org>> wrote:
>>>>>> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev <swift-
>>>> dev at swift.org <mailto:dev at swift.org>> wrote:
>>>>>> 
>>>>>> In swift_retain/release, we have an early-exit check to pass 
>>>> through a nil pointer. Since we're already burning branch, I'm 
>>>> thinking we could pass through not only zero but negative pointer 
>>>> values too on 64-bit systems, since negative pointers are never 
>>>> valid userspace pointers on our 64-bit targets. This would give us 
>>>> room for tagged-pointer-like optimizations, for instance to avoid 
>>>> allocations for tiny closure contexts.
>>>>> 
>>>>> We can't do that unless we can get a guarantee from the OS folks 
>>>> that a "negative" pointer will never be a valid userspace pointer in
>>>> any future OS version.
>>>> 
>>>> We have that guarantee, actually.  The top eight bits are guaranteed
>>>> to be clear in the user space on both ARM64 and x86-64.
>>> 
>>> This may be the case currently on Linux (even for non-x86 architectures),
>>> but what I have heard is that the kernel architecture allows using more
>>> levels of page tables, and the full 64-bit address space. The "guarantee"
>>> may not hold true in the future.
>>> 
>>> Negative pointer values are also used on other operating systems, so I
>>> would suggest not relying on this assumption for the sake of portability.
>> 
>> Sorry, I spoke too generally.  Obviously, this is a platform/kernel-specific
>> decision.  *Darwin* guarantees that the top eight bits are clear on userspace
>> data pointers on both ARM64 and x86-64.  If Linux makes weaker guarantees,
>> which seems likely to me, then we should make weaker assumptions on Linux.
> 
> Yeah, this would be a platform-specific decision. Linux x86-64 userspace at least still keeps to the positive side, since IIRC that's specified by the x86-64 SysV ABI, isn't it Bryan?

This could be further constrained to *refcountable* pointers if necessary. Even if the kernel for some reason decided to vend kernel-space addresses to userspace, it seems highly unlikely to me that address would point to a Swift-refcountable object.

-Joe

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