How to Manage Memory in PHP | 2
How to Manage Memory in PHP
Zend Memory Manager
The solution to memory leaks during request bailout is the Zend Memory Management (ZendMM) layer. This portion of the engine acts in much the same way the operating system would normally act, allocating memory to calling applications. The difference is that it is low enough in the process space to be request-aware so that when one request dies, it can perform the same action the OS would perform when a process dies. That is, it implicitly frees all the memory owned by that request. Figure 3.1 shows ZendMM in relation to the OS and the PHP process.
In addition to providing implicit memory cleanup, ZendMM also controls the perrequest
memory usage according to the
memory_limit. If a script
attempts to ask for more memory than is available to the system as a whole, or more
than is remaining in its per-request limit, ZendMM will automatically issue an
E_ERROR message and begin the bailout process. An added benefit of this is that the
return value of most memory allocation calls doesn't need to be checked because failure
results in an immediate
longjmp() to the shutdown part of the engine.
Hooking itself in between PHP internal code and the OS's actual memory management
layer is accomplished by nothing more complex than requiring that all memory
allocated internally is requested using an alternative set of functions. For example,
rather than allocate a 16-byte block of memory using
malloc(16), PHP code will use
emalloc(16). In addition to performing the actual memory allocation task, ZendMM
will flag that block with information concerning what request it's bound to so that
when a request bails out, ZendMM can implicitly free it.
Often, memory needs to be allocated for longer than the duration of a single request. These types of allocations, called persistent allocations because they persist beyond the end of a request, could be performed using the traditional memory allocators because these do not add the additional per-request information used by ZendMM. Sometimes, however, it's not known until runtime whether a particular allocation will need to be persistent or not, so ZendMM exports a set of helper macros that act just like the other memory allocation functions, but have an additional parameter at the end to indicate persistence.
If you genuinely want a persistent allocation, this parameter should be set to one, in
which case the request will be passed through to the traditional
malloc() family of
allocators. If runtime logic has determined that this block does not need to be persistent
however, this parameter may be set to zero, and the call will be channeled to the perrequest
memory allocator functions.
pemalloc(buffer_len, 1) maps to
pemalloc(buffer_len, 0) maps to
emalloc(buffer_len) using the following
Each of the allocator functions found in ZendMM can be found below along with their more traditional counterparts.
Table 3.1 shows each of the allocator functions supported by ZendMM and their e/pe counterparts:
You'll notice that even
pefree() requires the persistency flag. This is because at the time
pefree() is called, it doesn't actually know if
ptr was a persistent allocation or not.
free() on a non-persistent allocation could lead to a messy double free, whereas
efree() on a persistent one will most likely lead to a segmentation fault as the
memory manager attempts to look for management information that doesn't exist. Your
code is expected to remember whether the data structure it allocated was persistent or
In addition to the core set of allocator functions, a few additional and quite handy ZendMM specific functions exist:
len+1 bytes of memory and copy len bytes from
ptr to the newly allocated
block. The behavior of
estrndup() is roughly the following:
The terminating NULL byte implicitly placed at the end of the buffer here ensures that
any function that uses
estrndup() for string duplication doesn't need to worry about
passing the resulting buffer to a function that expects NULL terminated strings such as
printf(). When using
estrndup() to copy non-string data, this last byte is essentially
wasted, but more often than not, the convenience outweighs the minor inefficiency.
The amount of memory allocated by these functions is the result of
((size * count)
+ addtl). You may be asking,"Why an extra function at all? Why not just use
emalloc/pemalloc and do the math myself?" The reason comes in the name: safe.
Although the circumstances leading up to it would be exceedingly unlikely, it's possible
that the end result of such an equation might overflow the integer limits of the host
platform. This could result in an allocation for a negative number of bytes, or worse, a
positive number that is significantly smaller than what the calling program believed it
safe_emalloc() avoids this type of trap by checking for integer overflow and
explicitly failing if such an overflow occurs.
Not all memory allocation routines have a p* counterpart. For example, there is no
safe_pemalloc() does not exist prior to PHP 5.1. Occasionally you'll need to work around these gaps
in the ZendAPI.
Created: March 27, 2003
Revised: June 19, 2006