<html><body><p><tt>John McCall via swift-dev <swift-dev@swift.org> wrote on 2016-03-01 06:23:24 PM:<br><br>> > On Mar 1, 2016, at 3:05 PM, Greg Parker via swift-dev <swift-<br>> dev@swift.org> wrote:<br>> >> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev <swift-<br>> dev@swift.org> wrote:<br>> >> <br>> >> In swift_retain/release, we have an early-exit check to pass <br>> through a nil pointer. Since we're already burning branch, I'm <br>> thinking we could pass through not only zero but negative pointer <br>> values too on 64-bit systems, since negative pointers are never <br>> valid userspace pointers on our 64-bit targets. This would give us <br>> room for tagged-pointer-like optimizations, for instance to avoid <br>> allocations for tiny closure contexts.<br>> > <br>> > We can't do that unless we can get a guarantee from the OS folks <br>> that a "negative" pointer will never be a valid userspace pointer in<br>> any future OS version.<br>> <br>> We have that guarantee, actually. The top eight bits are guaranteed<br>> to be clear in the user space on both ARM64 and x86-64.</tt><br><br><tt>This may be the case currently on Linux (even for non-x86 architectures),</tt><br><tt>but what I have heard is that the kernel architecture allows using more</tt><br><tt>levels of page tables, and the full 64-bit address space. The "guarantee"</tt><br><tt>may not hold true in the future.</tt><br><br><tt>Negative pointer values are also used on other operating systems, so I</tt><br><tt>would suggest not relying on this assumption for the sake of portability.</tt><br><br><tt>Bryan</tt><br><tt><br></tt><BR>
</body></html>