PHP Memory Management Detailed

In c directly using malloc, free for memory allocation and release, but the frequent allocation and release of memory can produce memory fragmentation, reduce system performance, PHP variable allocation and release will be very frequent, if directly through malloc love distribution, can cause serious performance problems, As a language-level application, this loss is not acceptable, so PHP implemented its own memory pool ZENDMM, to replace the glibc malloc and free, to solve the problem of frequent allocation of memory, release.
It defines chunk, page, slot three granularity of memory operations, each chunk size is 2MB, each page 4kB, a chunk cut into 512 page, each page cut into several slots, when requesting memory, according to the size of the request, Perform different allocation policies
Huge: More than 2MB, directly call system allocation, assign several chunk
Large: request memory greater than 3092B (3/4page), less than 2044KB (511page) allocation of several page
Small: application memory is less than 3092B, the memory pool is defined in advance 30 different sizes of memory (8, 16, 32 ..., 3072), they are distributed on different page, the memory is requested directly in the corresponding memory to find the corresponding slot, the memory pool through ZEND_MM_ The heap structure stores the main information of the memory pool, such as the large Memory chain list, the chunk list, the slot size memory chain list, etc.
Large memory allocations are actually several chunk, which are then managed by a zend_mm_huge_list structure, and the large memory forms a one-way list
Chunk is the memory pool to the system to request, free memory of the minimum granularity, chunk form a doubly linked list, the first chunk address is saved in Zend_mm_heap->main_chunk, the first page of memory is used to save chunk own structure members, For example, the front and back chunk pointers, the current chunk page usage, etc.
A single-linked list between slots of the same size

The initialization of the memory pool is done in the php_module_startup phase, and the initialization process is primarily allocating the heap structure, which is done in the Start_memory_manager process, and if it is a multithreaded environment, each thread is allocated a pool of memory. Threads do not affect each other, the initialization will be based on the environment variable use_zend_alloc_huge_pages to set whether to open the memory large page, non-thread-safe environment, the allocated heap will be saved to Alloc_globals is the AG macro, it should be noted that Zend_ MM_HEAP This structure is not allocated separately, embedded in the chunk structure, because the chunk structure occupies a page, but in fact it does not use so much memory, in order to make the most use of space, put it here

Memory allocation: 1. Huge more than 2MB of memory allocation, when allocated, it will be aligned to n Chunk, will also allocate a zned_mm_huge_list structure, management of all huge memory, memory alignment process is the memory pool after the application to adjust themselves, rather than simply by the operating system to complete, The actual size will be applied once, if you can achieve memory alignment, no adjustment, direct return to use, if not zend_mm_chunk_size (2MB) integer multiples, then ZENDMM will release the memory, and then according to the actual memory size +zend_mm_ Chunk_size again application, the more application of the piece is used to adjust the 2. Large allocation: When the requested memory size is between 3072B (3/4page) and 2044k (511 page), the memory pool will find the corresponding number of page returns on chunk, large request granularity is Page,chunk Free_ Map and map two members are used to record page assignment information
Free_map is the 512bit, used to record the page allocation on the chunk, the use of the position 1
Map is used to record the page assignment type and the page pages allocated, each page corresponds to an array member, the maximum 2-bit record page's assignment type, 01 is large, 10 is small, the allocation starts from the first chunk traversal, Find chunk whether there is a page to meet the requirements, if the current chunk does not have the appropriate, then find the next chunk, if until the end there is no appropriate, then reassign a chunk, when applying, I do not know who found enough pages of page, but as far as possible to fill the chunk of space, Connect to the assigned page as much as possible, avoiding page gaps in the middle (to reduce the number of lookups on subsequent allocations) 1) Start with the first chunk group (0~63), the current group has a page, the current page's bit is detected first, Find the location of the first and last free page, if not enough to mark these page as 1 (allocated), to find other groupings, if the page is right, then directly use, interrupt retrieval, if the page is larger than needed, the representation is available, but not optimal, Will then look for other chunk until the last comparison is made with an optimal (maximum use of page) 2) after finding the appropriate page, set the appropriate page information, i.e. Free_map and map information and return to page address 3. Small allocation:
Will first check that the corresponding specifications of the memory is allocated, if not allocated or the allocation has been used, the page to request the corresponding page, page allocation process and large allocation consistent, after the request to page, according to the fixed size cut into slots, slots with a single linked list connection, the list head saved to AG ( MM_HEAP)->free_slot

The granularity of the memory pool release is chunk, which is accomplished by the Efree 1. Huge the release of memory, large, smal type because the first page of chunk is occupied, so it is not possible to have a relative chunk offset of 0, thus distinguishing between chunk type and large, small type, release, will occupy the chunk release, Remove 2 from the AG list at the same time. Large Memory release: If the calculated offset is not 0, indicating that the address is large or small memory, and then based on the offset to calculate the number of page, after the page can be obtained from the page of the assignment type, The specified type of memory can be freed, large does not directly release, but the page allocation information is not allocated, if released, and found to be unallocated under the chunk, then release chunk, release the preferred choice to move Chunk to AG, When the number of caches reaches a certain value, it is no longer necessary to cache the newly added chunk, return the memory to the system, avoid excessive memory, and, when allocating chunk, find the cache chunk in the chached_chunks to be removed directly, and do not issue a request to the system 3. The release of the small type, directly inserting the freed slot back into the list of available links in the rule slot, is relatively simple

In c directly using malloc, free for memory allocation and release, but the frequent allocation and release of memory can produce memory fragmentation, reduce system performance, PHP variable allocation and release will be very frequent, if directly through malloc love distribution, can cause serious performance problems, As a language-level application, this loss is not acceptable, so PHP implemented its own memory pool ZENDMM, to replace the glibc malloc and free, to solve the problem of frequent memory allocation, release

It defines chunk, page, slot three granularity of memory operations, each chunk size is 2MB, each page 4kB, a chunk cut into 512 page, each page cut into several slots, when requesting memory, according to the size of the request, Perform different allocation policies
Huge: More than 2MB, directly call system allocation, assign several chunk
Large: request memory greater than 3092B (3/4page), less than 2044KB (511page) allocation of several page
Small: application memory is less than 3092B, the memory pool is defined in advance 30 different sizes of memory (8, 16, 32 ..., 3072), they are distributed on different page, the memory is requested directly in the corresponding memory to find the corresponding slot, the memory pool through ZEND_MM_ The heap structure stores the main information of the memory pool, such as the large Memory chain list, the chunk list, the slot size memory chain list, etc.
Large memory allocations are actually several chunk, which are then managed by a zend_mm_huge_list structure, and the large memory forms a one-way list
Chunk is the memory pool to the system to request, free memory of the minimum granularity, chunk form a doubly linked list, the first chunk address is saved in Zend_mm_heap->main_chunk, the first page of memory is used to save chunk own structure members, For example, the front and back chunk pointers, the current chunk page usage, etc.
A single-linked list between slots of the same size

The initialization of the memory pool is done in the php_module_startup phase, and the initialization process is primarily allocating the heap structure, which is done in the Start_memory_manager process, and if it is a multithreaded environment, each thread is allocated a pool of memory. Threads do not affect each other, the initialization will be based on the environment variable use_zend_alloc_huge_pages to set whether to open the memory large page, non-thread-safe environment, the allocated heap will be saved to Alloc_globals is the AG macro, it should be noted that Zend_ MM_HEAP This structure is not allocated separately, embedded in the chunk structure, because the chunk structure occupies a page, but in fact it does not use so much memory, in order to make the most use of space, put it here

Memory allocation: 1. Huge more than 2MB of memory allocation, when allocated, it will be aligned to n Chunk, will also allocate a zned_mm_huge_list structure, management of all huge memory, memory alignment process is the memory pool after the application to adjust themselves, rather than simply by the operating system to complete, The actual size will be applied once, if you can achieve memory alignment, no adjustment, direct return to use, if not zend_mm_chunk_size (2MB) integer multiples, then ZENDMM will release the memory, and then according to the actual memory size +zend_mm_ Chunk_size again application, the more application of the piece is used to adjust the 2. Large allocation: When the requested memory size is between 3072B (3/4page) and 2044k (511 page), the memory pool will find the corresponding number of page returns on chunk, large request granularity is Page,chunk Free_ Map and map two members are used to record page assignment information
Free_map is the 512bit, used to record the page allocation on the chunk, the use of the position 1
Map is used to record the page assignment type and the page pages allocated, each page corresponds to an array member, the maximum 2-bit record page's assignment type, 01 is large, 10 is small, the allocation starts from the first chunk traversal, Find chunk whether there is a page to meet the requirements, if the current chunk does not have the appropriate, then find the next chunk, if until the end there is no appropriate, then reassign a chunk, when applying, I do not know who found enough pages of page, but as far as possible to fill the chunk of space, Connect to the assigned page as much as possible, avoiding page gaps in the middle (to reduce the number of lookups on subsequent allocations) 1) Start with the first chunk group (0~63), the current group has a page, the current page's bit is detected first, Find the location of the first and last free page, if not enough to mark these page as 1 (allocated), to find other groupings, if the page is right, then directly use, interrupt retrieval, if the page is larger than needed, the representation is available, but not optimal, Will then look for other chunk until the last comparison is made with an optimal (maximum use of page) 2) after finding the appropriate page, set the appropriate page information, i.e. Free_map and map information and return to page address 3. Small allocation:
Will first check that the corresponding specifications of the memory is allocated, if not allocated or the allocation has been used, the page to request the corresponding page, page allocation process and large allocation consistent, after the request to page, according to the fixed size cut into slots, slots with a single linked list connection, the list head saved to AG ( MM_HEAP)->free_slot


The granularity of the memory pool release is chunk, which is accomplished by the Efree 1. Huge the release of memory, large, smal type because the first page of chunk is occupied, so it is not possible to have a relative chunk offset of 0, thus distinguishing between chunk type and large, small type, release, will occupy the chunk release, Remove 2 from the AG list at the same time. Large Memory release: If the calculated offset is not 0, indicating that the address is large or small memory, and then based on the offset to calculate the number of page, after the page can be obtained from the page of the assignment type, The specified type of memory can be freed, large does not directly release, but the page allocation information is not allocated, if released, and found to be unallocated under the chunk, then release chunk, release the preferred choice to move Chunk to AG, When the number of caches reaches a certain value, it is no longer necessary to cache the newly added chunk, return the memory to the system, avoid excessive memory, and, when allocating chunk, find the cache chunk in the chached_chunks to be removed directly, and do not issue a request to the system 3. The release of the small type, directly inserting the freed slot back into the list of available links in the rule slot, is simple.