Implementation of the memory pool (ii)

In the memory pool implementation (i), this paper introduces the reasons for using the memory pool, designs the problems that should be considered in the memory pool, and finally gives a simple memory pool implementation example. Using the memory pool implementation described in the previous article, under certain constraints, let's look at a more general memory pool implementation of the--apache server's memory pool.

The Apache server developer collates the portable parts of the code into the Apache Portable runtime (apacheportable run-timelibraries), or APR, which can be downloaded from here, This contains the implementation code for the memory pool to be covered here. The Apache server memory pool is referred to as the APR memory pool below.

APR memory Pool structure 1. Memory allocation node

Before understanding the entire memory pool architecture, let's take a look at the most basic unit in the APR memory pool-The memory allocation node. Memory allocation nodes are used to describe each allocated block of memory, the corresponding structure named apr_memnode_t, defined in the file Apr_allocator.h, which is defined as follows:

/* Basic memory nodestructure*/struct  apr_memnode_t {apr_memnode_t*next;     & nbsp;    /**< Next Memnode * *      apr_memnode_t**ref;           /**< reference to self */     apr_uint32_t  index;             /**< Size */      apr_uint32_t  free_index;      /**< how much free * *   & nbsp;  char          *first_avail;          /**< Pointer to the memory */     char   & nbsp;      *endp;                 /**< Pointer to end of the free memory */};

Even though each field in the structure is commented on in the source file, it is difficult to understand the purpose of each field. Here we give you a brief explanation of each field: Next: A pointer to the next node; Ref: To the next node on the previous node, next to the last node points to this node, so **ref is the node itself; Index: both indicates the size of the node, At the same time, it indicates the index subscript value of the linked list of the node; Free_index: The unused space in the memory block described (here and above the index and their literal meaning, to be aware of); First_avail: A pointer to the starting position of the available space; ENDP: A pointer to the end position of the free space.

The schematic diagram of the node is as follows:

2. Memory Allocator

In the ARP memory pool, the memory allocation node is managed using a memory allocator, which is defined in APR_POOLS.C as follows:

struct apr_allocator_t {apr_uint32_t max_index;      apr_uint32_t Max_free_index;      apr_uint32_t Current_free_index;      apr_pool_t *owner; apr_memnode_t * Free [max_index]; };

Max_index:free the subscript of an array of pointers, Free[max_index] points to an existing maximum memory block list; Max_free_index: The maximum amount of memory space the memory allocator can hold; current_free_ Index: Memory allocator can also receive the size of the space, combined with max_free_index to solve the problem of limiting the size of the memory pool; Owner: Indicates which memory pool the allocator belongs to; free: point to the header of a list of linked lists, Each node in the list points to a linked list of memory nodes, Max_index 20.

The memory allocator and its managed memory nodes are illustrated as follows:

From the above, we can clearly see that the subscript of free array from 1 to max_index-1, point to a fixed chain of nodes, the subscript increased by 1, the size of the node increased by 4k, so Free[max_index] point to the linked list node size is 84k, This is also the largest "rule node" that the memory pool user can apply for, and the node that exceeds that size is managed by the linked list pointing to subscript 0. To understand the relationship between free array subscript and node size, we need to know the macro definition apr_align: