> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev <swift-dev@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.

I'd like to resurrect this thread as we look to locking down the ABI. There 
were portability concerns about doing this unilaterally for all 64-bit targets, 
but AFAICT it should be safe for x86-64 and Apple AArch64 targets. The x86-64 
ABI limits the userland address space, per section 3.3.2:

Although the AMD64 architecture uses 64-bit pointers, implementations are only 
required to handle 48-bit addresses. Therefore, conforming processes may only 
use addresses from 0x00000000 00000000 to 0x00007fff ffffffff.

Apple's ARM64 platforms always enable the top-byte-ignore architectural 
feature, restricting the available address space to the low 56 bits of the full 
64-bit address space in practice. Therefore, "negative" values should never be 
valid user-space references to Swift-refcountable objects. Taking advantage of 
this fact would enable us to optimize small closure contexts, Error objects, 
and, if we move to a reference-counted COW model for existentials, small `Any` 
values, which need to be refcountable for ABI reasons but don't semantically 
promise a unique identity like class instances do.

swift-dev mailing list

Reply via email to