Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,930
    • Issues 4,930
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 461
    • Merge requests 461
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #9806
Closed
Open
Created Nov 17, 2014 by Edward Kmett@ekmett

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking