[GHC] #9806: malloc and mallocArray ignore Storable alignment requirements

GHC ghc-devs at haskell.org
Mon Nov 17 18:53:43 UTC 2014


#9806: malloc and mallocArray ignore Storable alignment requirements
-------------------------------------+-------------------------------------
       Reporter:  ekmett             |                   Owner:  ekmett
           Type:  bug                |                  Status:  new
       Priority:  normal             |               Milestone:
      Component:  Core Libraries     |                 Version:  7.8.3
       Keywords:                     |        Operating System:
   Architecture:  Unknown/Multiple   |  Unknown/Multiple
     Difficulty:  Unknown            |         Type of failure:
     Blocked By:                     |  None/Unknown
Related Tickets:  8627               |               Test Case:
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
 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.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9806>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list