Click to See Complete Forum and Search --> : Malloc alignment


dchidelf
02-24-2004, 06:54 PM
Does anyone know if ANSI C has a #define definition for the number of bytes malloc will align to? In most code I see it defined as sizeof(unsigned long), but is that always guaranteed to be the aligment?

Also, is there a #define for the size of the header malloc uses for each allocated block?

Thanks.

bwkaz
02-24-2004, 07:57 PM
Why would it matter?

The alignment of malloc is going to be "whatever the underlying OS / hardware require", AFAIK. And I really don't see the size of the malloc header making any difference... (though I'd like to be proven wrong on that one).

dchidelf
02-25-2004, 01:02 AM
For the most part the size of the headers doesn’t matter to me. It would just be nice to be able to reference a #define to know the size. I was doing comparisons between addresses returned by malloc and the headers would occasionally get in the way.

I am allocating a variable sized structure that contains an integer array. Depending on the sizes of the other elements of the structure there can be wasted space 1-7 bytes between the current allocated space and the next space malloc will allocate (based on an 8 byte alignment). If malloc would “waste” 4-7 bytes I increase the size of my integer array buy one, effectively getting one free integer that would have otherwise been wasted. It could be argued that this is a pointless optimization, but the main objective of the code I am writing is to pack as much data into memory as possible.

The code I have is something like this:

malloc_pad = (8 - (alloc_size & 0x0007)) & 0x0007; /* number of bytes malloc will add */
if(malloc_pad >= sizeof(unsigned int)) ++array_size;
alloc_size += malloc_pad;


The malloc pad is currently based on an 8 byte alignment. I was going to modify it and use a #define equal to sizeof(unsigned long) which appears to be what a lot of other code uses as the alignment value, but I was hoping maybe there was already a predefined #define that would be included on any ANSI C compiler.

jim mcnamara
02-25-2004, 08:33 AM
There is no #define like that, because some of what is involved is hardware based, as B said.

Word and longword alignment speed up memory access, which is why structs are padded. Instead of allocating structs of varying lengths, allocate structs of pointers. Then allocate one massive block of memory for a flat array, have pointers that determine where the local array in the struct starts. Don't put the array inside the struct.

dchidelf
02-25-2004, 11:31 AM
I am not allocating structs of varying lengths, I am allocating memory for a data structure of varying size. I am sorry if "structure" in the last message was confusing.

I am allocating the memory for the struct (which contains a char * and int *), a char array, and an int array in one malloc statement. I don't need to manage the seperate pieces differently (freeing one piece but not the others), so I use one malloc statement instead of three, reducing the overhead caused by multiple smaller mallocs.

Because malloc's alignment is supposed to correspond to the most restrictive alignment of all data types (long needs to be aligned on 8 byte boundaries), subsequent mallocs could leave a hole up to 7 bytes.
I modify the amount of memory I am requesting so it is aligned on the 8 byte boundaries so I can make use of that memory rather than creating holes.

I'll just create a couple of my own #defines.

Thanks