PHP garbage collection mechanism-payback period

Traditionally, the reference-count memory mechanism, like the previous PHP, could not handle circular reference memory leaks. However 5.3.0 PHP uses the synchronization algorithm in the article» Reference counting system for synchronization cycle recovery (Concurrent cycle Collection in Reference counted systems) to handle this memory leak problem.

The full description of the algorithm is somewhat beyond the scope of this section and will only cover the underlying part. First, we have to establish some basic rules, if a reference count increases, it will continue to be used, of course, it is no longer in the garbage. If the reference count is reduced to zero, the container in which the variable is located is cleared (free). That is, the garbage cycle (garbage cycle) is generated only when the reference count is reduced to a value other than 0. Second, in a garbage cycle, by checking whether the reference count is minus 1, and checking which variable containers have a reference number of zero, to find out which part is garbage.

To avoid having to check the garbage cycles that all reference counts may be reduced, the algorithm places all possible roots (possible roots are zval variable containers) in the root buffer (marked with purple), which ensures that each possible garbage root ( Possible garbage Root) appears only once in the buffer. Garbage collection is performed on all the different variable containers inside the buffer only when the root buffer is full. Look at step A.

In step B, the algorithm uses a depth-first search to find all possible roots, and when found, the reference count in each variable container is reduced by "1", to ensure that the same variable container is not minus two "1" and the gray mark has been reduced by "1". In step C, the algorithm once again uses a depth-first search for each root node, checking the reference count for each variable container. If the reference count is 0, the variable container is marked with white (blue in the figure). If the number of references is greater than 0, restore the reference count minus "1" (that is, the reference count Plus "1") using depth-first search at this point, and then re-mark them with black. In the last step, D, the algorithm traverses the root buffer to remove the variable container root (Zval roots) from there, while checking for a variable container that was marked white in the previous step. Each variable container that is marked with white is cleared.

Now that you have a basic understanding of the algorithm, let's look back at how this integrates with PHP. By default, the garbage collection mechanism of PHP is open, and then there is a php.ini setting that allows you to modify it: ZEND.ENABLE_GC.

When the garbage collection mechanism is turned on, the loop lookup algorithm described above is executed whenever the root buffer is full. The root buffer has a fixed size, can save 10,000 possible roots, of course, you can modify the PHP source file zend/zend_gc.c in the constant gc_root_buffer_max_entries, and then recompile PHP, to modify this 10,000 value. When the garbage collection mechanism shuts down, the loop lookup algorithm never executes, however, it is possible that the root will always exist in the root buffer, regardless of whether the garbage collection mechanism is activated in the configuration.

When the garbage collection mechanism shuts down, if the root buffer is full of possible roots, the more likely root will obviously not be logged. The possible roots that are not recorded will not be analyzed by this algorithm. If they are part of a circular reference cycle, they will never be purged and thus cause a memory leak.

Even if the garbage collection mechanism is not available, it is possible that the root is also logged because it is faster to log a possible root operation than to check whether the garbage collection mechanism is turned on each time a possible root is found. However, the garbage collection and analysis mechanism itself will take some time.

In addition to modifying the configuration zend.enable_gc, the garbage collection mechanism can be turned on and off by invoking the gc_enable () and gc_disable () functions, respectively. Calling these functions is the same as modifying a configuration item to turn garbage collection on or off. Cycle recycling can be enforced even when the root buffer may not be full. You can call the Gc_collect_cycles () function to achieve this. This function returns the number of cycles recycled using this algorithm.

The reason that the garbage collection mechanism is allowed to turn on and off and allow autonomous initialization is due to the fact that some part of your application may be highly-sensitive. In this case, you may not want to use the garbage collection mechanism. Of course, shutting down the garbage collection mechanism for some part of your application is at the risk of a possible memory leak because some of the possible roots may not be in the limited root buffer. Therefore, it might be wise to call the Gc_collect_cycles () function before you call the Gc_disable () function to free memory. Because this clears all possible roots that have been stored in the root buffer, then when the garbage collection mechanism is closed, an empty buffer can be left in order to have more space to store the possible root.

