The allocation policy of STL memory manager

STL provides a number of generic containers, such as vector,list and map. Programmers use these containers only to care about when to plug objects into the container, not to care about how to manage memory, how much memory to use, these STL containers greatly facilitate the writing of C + + programs. For example, you can create a vector with the following statement, which is actually an on-demand dynamic array, with each element having an int integer type:

Stl::vector<int> Array;

With such a dynamic array, the user simply calls the Push_back method to add the object, without having to consider how much memory is required:

Array.push_back (10);
Array.push_back (2);

The vector automatically grows memory as needed, and the occupied memory is automatically destroyed when the array exits its scope, which is transparent to the user, and the STL container cleverly avoids tedious and error-prone memory management work.

The memory management work that is hidden behind these containers is implemented by a default allocator provided by the STL. Of course, users can also customize their own allocator, as long as the implementation of the interface method defined by the allocator template, and then by passing the custom allocator as template parameters to the STL container, create a custom allocator using the STL container object, Such as:

Stl::vector<int, userdefinedallocator> array;

In most cases, the STL default allocator is sufficient. This allocator is a memory manager consisting of a two-level allocator, and when the requested memory size is greater than 128byte, start the first-level allocator to allocate directly to the system's heap space via malloc, and if the requested memory size is less than 128byte, start the second-level allocator, Take a piece of memory from a pre-allocated pool of memory to the user, which consists of 16 free lists of different sizes (multiples of 8, 8~128byte), allocator depending on the size of the requested memory (this size round Up to a multiple of 8) takes the header block from the corresponding free block list to the user.

There are two advantages to this approach:

1) Quick allocation of small objects. The small object is allocated from the memory pool, this memory pool is a system called malloc allocated a large enough area for the program to spare, when the memory pool exhausted and then to the system to apply for a new area, the whole process is similar to wholesale and retail, at first by the allocator to total business wholesale a certain amount of goods, Then retail to the user, and every time the total business to a goods re-retail to users of the process compared to the obvious is fast. Of course, here's a problem when the memory pool will bring some waste of memory, such as when only a small object to allocate, for this small object may want to request a large pool of memory, but this waste is worthwhile, and this situation in practical application is not much see.

2) Avoid the generation of memory fragments. The allocation of small objects in the program is very easy to cause memory fragmentation, which brings great pressure on the memory management of the operating system, and the increase of fragmentation in the system will not only affect the speed of memory allocation, but also greatly reduce the utilization of memory. To organize the memory of small objects in a memory pool, from a system point of view, is just a large pool of memory, which does not see the allocation and release of small object memory.

When implemented, allocator needs to maintain an array free_list that stores 16 free block list headers, an array element i is a header that points to a list of free blocks with a block size of 8* (i+1) bytes, and a pointer to the memory pool start address Start_ Free and a pointer to the end address End_free. The structure of the Free Block list node is as follows:

Union obj {
Union obj *free_list_link;
Char client_data[1];
};

This structure can be seen as keying out 4 bytes from a block of memory, when the memory block is idle, it stores the next free block when the memory block is delivered to the user, and it stores the user's data. Therefore, the free block list in allocator can be expressed as: obj* free_list[16];

Allocator allocates memory in the following algorithm:

Algorithm: Allocate
Input: Size of application memory
Output: Returns the address of a memory if the assignment is successful, otherwise returns null
{
if (size greater than 128) {starts the first level allocator directly calls malloc to allocate the required memory and returns the memory address;
else {
Round the size up by a multiple of 8 and takes the corresponding header free_list_head from the free_list according to the size;
If (Free_list_head is not empty) {
Remove the first free block from the list and adjust the free_list;
return to Free_list_head;
}
} else {
Call the refill algorithm to create a list of free blocks and return the desired memory address;
}
}

Re-fill algorithm:

Algorithm: Refill
Input: Size of memory block
Output: Establishes a free block list and returns the first available memory block address
{
Call the CHUNK_ALLOC algorithm to allocate several contiguous memory areas of size and return the start address chunk and the number of successfully allocated blocks nobj;
if (block number 1) return directly to chunk;
else{
Start to establish free_list in the chunk address block;
The corresponding header element in Free_list is taken from size free_list_head;
Point the Free_list_head at the address in chunk where the start address is size, that is, free_list_head= (obj*) (chunk+size);
The remaining nobj-1 memory blocks in the whole chunk are then concatenated together to form a free list;
Returns chunk, which is the first block of free memory in the chunk;
}
}

Block allocation algorithm

Algorithm: Chunk_alloc
Input: Size of memory block, number of pre-allocated memory blocks Nobj (pass by reference)
Output: The address of a contiguous memory area and the number of blocks of memory that can be accommodated within the region
{
Calculate the total required memory size total_bytes;
if (the memory pool is sufficient to allocate, i.e. End_free-start_free >= total_bytes) {
Update the Start_free;
Return to the old Start_free;
}
else if (the memory pool is not nobj enough to allocate a block of memory, but at least one can be assigned) {
Calculates the number of memory blocks that can be allocated and modifies the nobj;
Update Start_free and return to the original start_free;
}
else {//memory pool cannot allocate a block of memory
First, the memory block of the memory pool is chained into the corresponding free_list;
Call the malloc operation to reallocate the memory pool, the size is twice times the Total_bytes plus the additional amount, Start_free points to the memory address that is returned;
if (Assignment is unsuccessful) {
if (there are free blocks in 16 free lists)
Try to call Chunk_alloc (size, nobj) back into the memory pool of the free block in the 16 free list;
Else
It is also useful to call the first level allocator to try out the memory mechanism;
}
}
Update End_free to Total_bytes of start_free+total_bytes,heap_size for twice times;
Call Chunk_alloc (size,nobj);
}

Assuming such a scenario, free_list[2] has pointed to a 24-byte free Block list, 1 shows that when the user requests a 21-byte block of memory to allocator, ALLOCAOTR first checks free_list[2] and free_list[2 ] refers to the memory block that is assigned to the user, and then points the table header to the next available free block, as shown in 2. Note that when a memory block is on a linked list, the first 4 bytes are used as points to the next free block, and when assigned to the user, it is a common memory area.

Figure 1 Status of allocator at some point

Figure 2 Allocating a 24-byte block of memory

http://blog.csdn.net/adcxf/article/details/6437880

The allocation policy of STL memory manager