Andrew Trick 0b5fa792e1 Force manual allocation (via Unsafe*Pointer) to use >= 16 alignment. ...

This fixes the Windows platform, where the aligned allocation path is
not malloc-compatible. It won't have any observable difference on
Darwin or Linux, aside from manually allocated memory on Linux now
being consistently 16-byte aligned (heap objects will still be 8-byte
aligned on Linux).

It is unfortunate that we can't guarantee Swift-allocated memory via
Unsafe*Pointer is malloc compatible on Windows. It would have been
nice for that to be a cross platform guarantee since it's normal to
allocate in C and deallocate in Swift or vice-versa. Now we have to
tell developers to always use _aligned_malloc/_aligned_free when
transitioning between Swift/C if they expect their code to work on
Windows.

Even though this fix isn't required today on Darwin/Linux, it makes
good sense to guarantee that the allocation/deallocation paths are
consistent.

This is done by specifying a constant that stdlib can use to round up
alignment, _swift_MinAllocationAlignment. The runtime asserts that
this constant is greater than MALLOC_ALIGN_MASK for all platforms.
This way, manually allocated buffers will always use the aligned
allocation path. If users specify an alignment less than m

round up so users don't need
to pass the same alignment to deallocate the buffer). This constant
does not need to be ABI.

Alternatives are:

1. Require users of Unsafe*Pointer to specify the same alignment
   during deallocation. This is obviously madness.

2. Introduce new runtime entry points:
   swift_alignedAlloc/swift_alignedDealloc, introduce corresponding
   new builtins, and have Unsafe*Pointer always call those. This would
   make the runtime API a little more obvious but would introduce
   complexity in other areas of the compiler and it doesn't have any
   other significant benefit. Less than 16-byte alignment of manually
   allocated buffers on Linux is a non-goal.

2019-01-03 12:35:51 -08:00

4.3 KiB

Raw Blame History

View Raw