Heap memory: Gap of 16 bytes for 8 byte struct - c

Question

I'm using the following code to create and insert a new node into a linked list, subsequently freeing them.
// the node
struct node
{
int data;
struct node *next;
};
// returns a pointer to a new node with data
struct node *new_node(int data)
{
struct node *node;
node = malloc(sizeof(struct node));
node->data = data;
node->next = NULL;
return node;
}
// insert node at front of list
void push(struct node **head, int data)
{
struct node *node = new_node(data);
node->next = *head;
*head = node;
}
// free the list, deallocate each node's memory
void delete_list(struct node** head)
{
if(*head == NULL)
return;
struct node *next = NULL;
next = (*head)->next;
while(next != NULL)
{
next = (*head)->next;
// print address of the memory released
printf("Freeing %d\n", (int)*head);
free(*head);
*head = next;
}
}
Now, the struct is 8 bytes in my machine (4 byte int and 4 byte pointer). Now, I'm a bit unsure about the following, so please help me out:
When I call push() in sequence, is the memory allocated contiguously? Is that always the case? I guess it cannot be, for the memory in heap can be fragmented.
Say the memory allocated was contiguous, then would it be spaced 8 bytes apart, since the struct's size is 8 bytes. On my machine, when I printed the address of the memory being freed, the memory addresses printed are 16 bytes apart, on every execution. Why?
Freeing 148025480
Freeing 148025464
Freeing 148025448
Freeing 148025432
Freeing 148025416
Freeing 148025400
Freeing 148025384
Freeing 148025368
Freeing 148025352
<empty list>
Now if the memory was NOT allocated contiguously for our integer array (the heap was very much fragmented, and memory requirement was quite large), and we used pointer arithmetic to process each element of the array by incrementing the address by 4 each time(or whatever the size of int is), shouldn't we run into some memory not reserved by our program, throwing off the program? Or is the runtime environment smart enough to take care of this, as the compiler cannot, for it doesn't know how the memory will be allocated. Does the OS take care of this?

Answer 1

Each time you call new_node, it calls malloc().
You cannot (or should not) predict where malloc() will find you memory. It is OS and runtime dependent.
Running on a particular OS, under certain circumstances, you might observe that allocations from consecutive calls to malloc() are contiguous. However that behaviour may change under load, or with a kernel update, a change in the implementation of libc, or under all kinds of other conditions.
You can assume that the chunk of memory allocated by a single call to malloc() is contiguous (at least, in terms of the pointers your program sees). Your program should not assume anything else about contiguity.
If this really bothers you, you can take charge of more of the memory management in your own code -- instead of calling malloc() for each node, call it at the start and get a larger chunk of memory. Subsequent calls to new_node can use part of this chunk. If you run out of space in that chunk, you can either malloc() another chunk (which probably won't be contiguous with the first) or realloc() to extend (and probably move) it.
You'll probably find that all this makes your code more complicated -- and it's up to you whether there are benefits to counter that. The authors of the Hotspot Java VM essentially do this - they malloc() a big block of memory at the start of execution, then rather than call malloc() and free() when the Java program wants memory, it uses its own routines to allocate parts of that block.

Answer 2

Regarding #2, one reason for the results of calls to malloc not being exactly contiguous can be metadata: when you ask for x bytes, malloc implementations may allocate a little extra memory for internal bookkeeping processes (tagging the size of the block, pointers to other free blocks, etc). Thus a request for 8 bytes may actually cause 16 bytes to be allocated internally, hence the 16-byte spacing between successive allocations.

Answer 3

If you allocate memory using malloc, the memory returned will always be contiguous.
If you call malloc twice, there's no guarantee that the two allocations will be placed next to each other, not even if the two malloc calls are right next to each other.

Answer 4

When allocating memory using malloc() you would see a gap of 1-Word size in memory allocations, i.e. 16-Bytes extra would be allocated. This is normal as this is due to the fact that we might want to use free() method for deallocating the memory. The extra space is used by the free() method as a scratch space while performing deallocation operations.
Let say we have the following 2D array:
1 2 3
4 5 6
7 8 9
And the starting address of array is 448 (also the memory address of '1')
Then the memory address for '1', '4', '7' would be 448, 480, 512 respectively which could be calculated as follows:
448 + (3 x 4) + 4 + 16 = 480
Here, we have:
448 - Address of the previous block
3 - Number of columns or number of items in the array
4 - Size of int (I'm assuming the array as integer array)
4 - Extra four bytes because size of int is 4 bytes. So the last int address + 4
16 - As left by the malloc for free() function
I hope it clarifies a little.