Memory Manager Diagrams

Heap Management

Implementing a heap using a linked list

The heap is allocated as a single contiguous chunk of memory
To keep track of allocated and unallocated blocks within the heap, we maintain a list that stores the following information about each block:

Allocation flag: 0 if unallocated, 1 if allocated
Address: beginning address of the block
Size: number of bytes in the block

List items are ordered by start address.

An alternate scheme is to order the blocks by size.

To allocate a block of memory of size bytes:

Search list for available hole (unallocated block) that is at least size bytes long (see later)
Remove the item from the list and replace it with two list items:

First item represents an allocated block of size bytes, with same start address as original block
Second item represents an unallocated block (hole) for the remaining unused bytes of the original block

Return:

NULL pointer, if no block found in list
Start address of allocated block, if block is found in list

To deallocate (free) a block:

Search for item in the list whose start address is the specified address
Mark item as unallocated
Consolidate adjacent unallocated memory into a single unallocated block

Merge with the preceding memory block if it is currently unallocated
Merge with the succeeding memory block if it is currently unallocated

We keep track of each block of memory using a structure:

struct block_info 
{
  int allocated;           /* Is the block in use?              */
  char *address;           /* The starting address of the block */
  int size;                /* The size of the block             */
  struct block_info *next; /* The next block                    */
};

Visually (assume 32-bit computer):

Creating the first block_info and allocating memory:

#define HEAP_SIZE 2000          /* Size of the memory to manage      */
struct block_info *Heap_blocks; /* Head of the linked list of blocks */

Heap_blocks = malloc(sizeof(block_info)); /* Allocate the struct to manage the memory allocated above */

Heap_blocks->allocated = 0;               /* It's currently all available */
Heap_blocks->address = malloc(HEAP_SIZE); /* Allocate the actual memory   */
Heap_blocks->size = HEAP_SIZE;            /* The total size of the memory */
Heap_blocks->next = NULL;                 /* The next block               */

Initial heap. This example shows that the heap starts at address 0. In practice, the memory would not be located at address 0, but some arbitrary address much farther away. It starts at 0 to make the example easier to follow.

After allocating a block of 300 bytes:

After allocating a block of 200 bytes:

After allocating a block of 400 bytes:

After freeing the block at address 300:

After freeing the block at address 0: (step 1)

After merging the two smaller adjacent free blocks into one large free block: (step 2)

After allocating a block of 700 bytes:

After allocating a block of 300 bytes (using first-fit):

After allocating (the same) block of 300 bytes (using best-fit):

More details about the structure layout in memory (comparing 32-bit with 64-bit computers):

32-bit system
(logical view) 32-bit system
(physical view)
16 bytes 64-bit system
(logical view) 64-bit system
(physical view)
32 bytes

Given this information, a more efficient way to layout the structure is like this:
struct block_info 
{
  int allocated;           /* Is the block in use?              */
  int size;                /* The size of the block             */
  char *address;           /* The starting address of the block */
  struct block_info *next; /* The next block                    */
};
Visually (24 bytes):

You can have gcc alert (warn) you when the compiler is adding padding between the fields of a struct. Just use the -Wpadded option when compiling the code. The message from gcc when compiling the original struct above looks like this:
struct.c:4:9: warning: padding struct to align 'address' [-Wpadded]
   char *address;
         ^~~~~~~
struct.c:6:22: warning: padding struct to align 'next' [-Wpadded]
   struct block_info *next;
                      ^~~~

Strategies for handling memory requests

It's possible that we have many different sized blocks on our list
When allocating a block of size bytes, we may have a choice among various unallocated blocks of size at least size bytes
First fit - choose the first available hole

Fast.
May lead to fragmentation.

Best fit - choose the smallest hole

Produces smallest remaining hole.
Entire list must be searched.

Worst fit - choose the largest hole

Produces the largest remaining hole.
Entire list must be searched.

Next fit - like first fit but starts where last search left off.

Likely to find an available block more quickly.

Quick fit - uses multiple lists

Each list contains blocks of the same size.
No need to search for a fit.