Did "malloc" allocated noaligned memory?

Did "malloc" allocated noaligned memory?


I have a question about alignment data. I tested "malloc" and saw that memory aligned on 16-byte. I retried this experiment, but result is same. 

Did "malloc" allocated noaligned memory? Or "malloc" allocated aligned memory on 16 byte? Options of compiler is standard.

Thanks for a answer.

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Best Reply

malloc has no requirement for alignment. However, most C runtime systems introduce an alignment that is an artifact of its heap managers node management. Most heap managers have at least a {Node* Next, intptr_t lenOfNode} header for nodes. This would place a minimum node size of 2*sizeof(void*). This often is 8 on 32-bit systems, and 16 on 64-bit systems. Heap managers, additionaly may introduce additional information either before or after the returned buffer. An example is when a C++ new[] allocates an array of objects. If your program requires alignment (e.g. for SSE/AVX) then use one of the aligned allocation routines available to your compiler such as _aligned_malloc, and you can also overload new, and new[] to provide alignment as well.

Jim Dempsey


Thanks Jim for the detailed answer!

On Linux, AFAIK malloc() returns pointer aligned to 16 bytes-boundary. On Windows not. On Windows you need to call _mm_malloc and _mm_free counterpart. see http://software.intel.com/sites/products/documentation/studio/composer/e...

With best regards,
If you find my post helpful, please rate it and/or select it as a best answer where applies. Thank you.

>>...Or "malloc" allocated aligned memory on 16 byte?...

You need to verify it with a C++ compiler and I see that you've done it. Intel, or Microsoft, or MinGW C++ compilers could have some differences.

Note: A couple of months ago I "switched" almost all memory allocations to _mm_malloc and _mm_free intrinsic functions because they are more flexible ( in my cases ). However, there are some issues with C++ operators new and delete since they could use malloc and free CRT functions.

I should add something to my prior comment. When using new[], my prior observaton was the heap manager managed nodes in multiple of 2x sizeof(void*) as described before. Now then although the raw node aligned on 8 (32-bit) or 16 (64-bit), the entry for the number of objects went into the first element (of size_t) in the node, then the returned memory pointer was at node+sizeof(size_t). Which almost always led to unaligned allocations for use with SSE. Most C memory managers have this fixed now, but you cannot rely on the alignment. Use _mm_malloc/_mm_free or alternate methods to enforce alignment for allocated objects (if this is a requirement).

Jim Dempsey


The_mm_malloc routine takes an extra parameter, which is the alignment constraint. This constraint must be a power of two. The pointer that is returned from_mm_malloc is guaranteed to be aligned on the specified boundary.

Note :Memory that is allocated using_mm_malloc must be freed using_mm_free. Calling freeon memory allocated with_mm_mallocor calling_mm_freeon memory allocated with malloc will cause unpredictable behavior.


Thank you. -- QIAOMIN.Q

Intel Developer Support

>>...Calling freeon memory allocated with_mm_mallocor calling_mm_freeon memory allocated with malloc will cause
>>unpredictable behavior...

In practice, it is very predictable and in that case an application always crashes.

If the application is compiled with Microsoft or Intel C++ compilers in Debug configuration an Assert message informs a developer that inconsistency with calls detected. I had some number of crashes during an initial phase of changing all calls to always alligned memory allocations using _mm_malloc and _mm_free intrinsic functions.

Leave a Comment

Please sign in to add a comment. Not a member? Join today