Does realloc keep the memory alignment of posix_memalign?

Question

Aligned malloc is posix_memalign, that's OK, but what about the aligned realloc? Does realloc retain the alignment or how to assure that reallocated memory has the same alignment? Assume Linux and x86_64.

Answer 1

No, realloc on the memory returned from posix_memalign is not guaranteed by either ISO or POSIX to maintain the same alignment. A realloc may simply expand the current block at the same address but it may also move the block to a different address whose alignment is less strict than the original.

If you want the same alignment, it's probably best to allocate another block and copy the data over.

There is, unfortunately, no posix_memalign_realloc function in the Single UNIX Specification either.

If you don't want to go through the hassle of copying data every time, you could try the realloc ^(a) and, if the alignment of that was not as expected, then and only then call posix_memalign to get a correctly aligned address and copy the data in to there, freeing the old address when done.

This may result in:

• zero copies (if the current block can be expanded in-place);
• one copy (if realloc copies but happens to give you a correctly aligned block); or
• two copies (if realloc copies and then you also have to copy due to misalignment).

It may also result in less copying than indicated depending on the underlying memory management implementation. For example, a "copy" may simply involve remapping memory blocks rather than physically moving the data.

So you may want to keep some statistics to see if this scheme is worthwhile.

---

^(a) Just keep in mind that neither POSIX nor Linux man pages specify whether or not you even can pass these pointers to realloc, only that you can pass them to free.

However, based on the current GNU libc source code, it appears to work, although that's no guarantee it will continue to work in future :-)

My fear was that it would allocate memory normally (standard alignment) and pass back an offset address (ie, not the actual address allocated, but one N bytes beyond that) which free was intelligent enough to turn back into the actual address before weaving its magic.

One way of doing that would be to store the actual address immediately before the returned address though this of course would lead to wastage even for regular allocations.

In that case, free may have been made intelligent (since the specs say it must be able to handle the allocations done by posix_memalign) but realloc may not have been given the same intelligence (since the docs are silent on that matter).

However, based on GNU glibc 2.14.1, it actually allocates more memory than needed then fiddles with the arena to free up the pre-space and post-space, so that the address returned is a "real" address, usable by free or realloc.

But, as stated, the documentation doesn't guarantee this.