malloc and mallocArray ignore Storable alignment requirements
Not sure if this is a bug or a feature request:
allocaBytesAligned
exists and allocates a new pinned byte array with a given alignment. It is used for both alloca
and allocaArray
.
However, we don't currently have such a facility with malloc
.
malloc
and mallocArray
currently just invoke mallocBytes
, and mallocBytes
requests memory without alignment guarantees, so the resulting memory might well violate required Storable
alignment
for the result.
We don't currently pad things out or get properly aligned memory.
It strikes me that we should in theory add mallocBytesAligned
, and switch malloc
and mallocArray
to invoke it instead of mallocBytes
.
Foreign.Marshal.Alloc.mallocBytes
just invokes system malloc
, so it seems that memalign
or posix_memalign
would be suitable.
In theory _malloc
on the system is probably aligning to a pretty common unit size, but if you start doing SIMD stuff you'll start seeing 16 byte alignment requirements, folks who care about cache architecture for example can have 128 byte alignments to pad things to separate cache lines.
We probably haven't noticed since you likely get back bytes with slot-sized alignment just by construction, so if your alignment requirements stay in the <= 8 range you'll be okay, but for larger alignments it appears you'd just get wrong answers.
If something more subtle is going on here (e.g. an alignment
bigger than some threshold wont be respected or that users should explicitly expect mallocArray
to silently allocate an array with the wrong alignment) that I missed then we definitely need better documentation to address the issue.
Trac metadata
Trac field | Value |
---|---|
Version | 7.8.3 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Core Libraries |
Test case | |
Differential revisions | |
BlockedBy | |
Related | #8627 |
Blocking | |
CC | core-libraries-committee@haskell.org |
Operating system | |
Architecture |