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

[John McCall]

> On Mar 8, 2016, at 2:24 AM, Bryan Chan <bryan.chan at ca.ibm.com> wrote:
> John McCall via swift-dev <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> wrote:
> > >> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev <swift-
> > 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.

John.