"Operating System" heap and memory allocation

It is not enough to program the object-oriented process because the data on the stack is freed when the function returns, so the data cannot be passed to the outside of the function. There is no way for global variables to be generated dynamically, only at compile time, there are many cases of lack of expressiveness. In this case, the heap is the only option

The heap is a huge memory space that often occupies the vast majority of the entire virtual memory space. In this space, the program can request a piece of contiguous memory, and free to use, this block of the existence of the program will remain active until the initiative. The following is the simplest example of an application heap space.

　　

1 int Main () 2 {3     Char * p= (char*)malloc(+); 4     /* Use p as an array of size of */ 5      Free (p); 6 }

After the third line has requested 1000 bytes of space with malloc, the program is free to use the 1000 bytes until the program releases it with the "free" function.

Heap allocation algorithm

　　For a program, heap space is just a chunk of the address space that the program requests from the operating system. It is not necessarily the size of the program to request memory space through malloc. From a few bytes to a few gigabytes is possible. So we have to manage the heap space, block it to the user's needs to sell to the final program, and can also recover memory in a certain way. In fact, this problem can be attributed to: how to manage a large chunk of memory space, can be allocated according to demand, the release of space, this is the heap allocation algorithm.

　　1. Idle link list

The free list method is actually to link the various free blocks in the heap to the linked list, and when the user requests a piece of space, it is possible to iterate through the entire listing until the appropriate size block is found and split: when the user requests a piece of memory space, it can traverse the entire list. Until you find a block of the appropriate size and split it: when the user frees up space, it is merged into the idle list.

We first need a data structure to rank all the idle time in the heap space so that we know which memory to allocate to the program when it requests space. There are many kinds of structures, and here is the simplest one--the idle list.

The idle list is a data structure that has a header (header) at the beginning (or end) of each free space in the heap, and the address of the previous (prev) and Next (next) free block is recorded in the header structure, that is, all the free blocks form a linked list. As shown in the following:

　　

First, find enough free blocks in the idle list to accommodate the request size, then divide the block into two parts, one for the requested space and the other for the remaining free space. The following structure of the original free block in the list is updated to the new remaining free block, and if the remaining free block size is 0, the structure is removed from the list directly. Disguise the state of the heap after the user requests a piece of memory that is exactly equal to the free block

Such an idle list implementation is simple, but when the space is freed, given a pointer to an allocated block, the heap cannot determine the size of the block. A simple workaround is when the user requests a K-byte space, we actually allocate k+4 bytes, which is used to store the size of the allocation, that is, K+4, 4 bytes. This frees up the memory by looking at the 4-byte value, knowing the size of the memory and inserting it into the idle list.

Of course, this is just the simplest kind of allocation strategy, there are many problems with this idea. For example, once the list is broken, or the 4 bytes of the record length are destroyed, the entire heap fails to function, and these are easily exposed to cross-read and write.

　

　　2. Bitmaps

When using the bitmap method, memory may be divided into small to few words or as large as thousands of bytes of allocation unit. Each allocation unit corresponds to one in the bitmap, 0 for idle, and 1 for occupancy.

The size of the allocation unit is an important design factor. The smaller the allocation unit, the larger the bitmap. However, even if there are only 4 bytes of allocation units, 32 bits of memory only need to Mughal 1 bits in the graph, 32n of memory requires n-bit bitmap, so the bitmap occupies only 1/33 of the memory. If you select a larger allocation unit, the bitmap is smaller. However, if the size of the process is not an integer multiple of the allocation unit, then a certain amount of memory is wasted in the last allocation unit.

Because the size of the memory and the size of the allocation unit determine the size of the bitmap, it provides a simple way to record memory usage using a fixed size memory area. The main problem with this approach is that when deciding to call a process that takes up a K allocation unit into memory, the storage Manager must search for the bitmap and find the K-contiguous 0 strings in the map. Finding successive 0 strings of a specified length in a bitmap is a time-consuming operation (because the string may span the boundaries of a word), which is a disadvantage of bitmaps.

"Operating System" heap and memory allocation