A brief discussion on the evolution of the garbage collection algorithm (Garbage Collection) in PHP5_PHP Tutorial

Foreword: PHP is a managed language. In PHP programming, programmers do not need to manually handle the allocation and release of memory resources (except when using C to write PHP or Zend extensions), which means that PHP itself implements The garbage collection mechanism (Garbage Collection) is implemented. Now if you go to the official PHP website (php.net) you can see that the current two branch versions of PHP5, PHP5.2 and PHP5.3, are updated separately. This is because many projects still use the 5.2 version of PHP, and the 5.3 version is 5.2 is not fully compatible. PHP5.3 has made many improvements based on PHP5.2, among which the garbage collection algorithm is a relatively big change. This article will discuss the garbage collection mechanisms of PHP5.2 and PHP5.3 respectively, and discuss the impact of this evolution and improvement on programmers writing PHP and the issues they should pay attention to.

Internal representation of PHP variables and associated memory objects

In the final analysis, garbage collection is the operation of variables and their associated memory objects, so before discussing PHP’s garbage collection mechanism, let’s briefly introduce the internal representation of variables and their memory objects in PHP (its representation in the C source code ).

The official PHP documentation divides variables in PHP into two categories: scalar types and complex types. Scalar types include booleans, integers, floating point types and strings; complex types include arrays, objects and resources; there is also a special NULL, which is not divided into any type, but becomes a separate category.

All these types are uniformly represented by a structure called zval within PHP. In the PHP source code, the name of this structure is "_zval_struct". The specific definition of zval is in the "Zend/zend.h" file of the PHP source code. The following is an excerpt of the relevant code.

 

typedef union _zvalue_value {
	long lval;					/* long value */
	double dval;				/* double value */
	struct {
		char *val;
		int len;
	} str;
	HashTable *ht;				/* hash table value */
	zend_object_value obj;
} zvalue_value;

struct _zval_struct {
	/* Variable information */
	zvalue_value value;		/* value */
	zend_uint refcount__gc;
	zend_uchar type;	/* active type */
	zend_uchar is_ref__gc;
};

The union "_zvalue_value" is used to represent the values ​​of all variables in PHP. The reason why union is used here is because a zval can only represent one type of variable at a time. You can see that there are only 5 fields in _zvalue_value, but there are 8 data types in PHP including NULL. So how does PHP use 5 fields to represent 8 types internally? This is one of the more clever aspects of PHP design. It achieves the purpose of reducing fields by reusing fields. For example, within PHP, Boolean types, integers and resources (as long as the identifier of the resource is stored) are stored through the lval field; dval is used to store floating point types; str stores strings; ht stores arrays (note that in PHP The array is actually a hash table); and obj stores the object type; if all fields are set to 0 or NULL, it means NULL in PHP, so that 5 fields are used to store 8 types of values.

What type the value in the current zval (the type of value is _zvalue_value) represents is determined by the type in "_zval_struct". _zval_struct is the specific implementation of zval in C language. Each zval represents a memory object of a variable. In addition to value and type, you can see that there are two fields refcount__gc and is_ref__gc in _zval_struct. From their suffixes, you can conclude that these two guys are related to garbage collection. That's right, PHP's garbage collection relies entirely on these two fields. Among them, refcount__gc indicates that there are several variables currently referencing this zval, and is_ref__gc indicates whether the current zval is referenced by reference. This sounds very confusing. This is related to the "Write-On-Copy" mechanism of zval in PHP. Since this topic is not This article is the focus, so I won’t go into details here. Readers only need to remember the role of the refcount__gc field.

Garbage collection algorithm in PHP5.2——Reference Counting

The memory recycling algorithm used in PHP5.2 is the famous Reference Counting. The Chinese translation of this algorithm is called "reference counting". Its idea is very intuitive and concise: assign a counter to each memory object. When a memory object is created The counter is initialized to 1 (so there is always a variable referencing this object at this time). Every time a new variable refers to this memory object, the counter increases by 1, and every time a variable that references this memory object is reduced, the counter decreases by 1. When the garbage collection mechanism operates, all memory objects with a counter of 0 are destroyed and the memory they occupy is reclaimed. The memory object in PHP is zval, and the counter is refcount__gc.

For example, the following piece of PHP code demonstrates the working principle of the PHP5.2 counter (the counter value is obtained through xdebug.org):

$val1 = 100; //zval(val1).refcount_gc = 1;
$val2 = $val1; //zval(val1).refcount_gc = 2,zval(val2).refcount_gc = 2(因为是Write on copy，当前val2与val1共同引用一个zval)
$val2 = 200; //zval(val1).refcount_gc = 1,zval(val2).refcount_gc = 1(此处val2新建了一个zval)
unset($val1); //zval(val1).refcount_gc = 0($val1引用的zval再也不可用，会被GC回收)

?>

$val1 = 100; //zval(val1).refcount_gc = 1;
$val2 = $val1; //zval(val1).refcount_gc = 2,zval(val2).refcount_gc = 2 (because it is Write on copy, currently val2 and val1 jointly reference a zval)
$val2 = 200; //zval(val1).refcount_gc = 1,zval(val2).refcount_gc = 1 (val2 creates a new zval here)
unset($val1); //zval(val1).refcount_gc = 0 (the zval referenced by $val1 is no longer available and will be recycled by GC)

?>

Reference Counting is simple, intuitive, and easy to implement, but it has a fatal flaw, which is that it can easily cause memory leaks. Many friends may have realized that if there is a circular reference, Reference Counting may cause memory leaks. For example, the following code:

$a = array();
$a[] = & $a;
unset($a);

?>

$a = array();
$a[] ​​= & $a;
unset($a);

?>

This code first creates the array a, and then lets the first element of a point to a by reference. At this time, the refcount of zval of a becomes 2. Then we destroy the variable a. At this time, the zval that a initially points to The refcount is 1, but we can no longer operate on it because it forms a circular self-reference, as shown in the figure below:

The gray part means it no longer exists. Since the refcount of the zval pointed to by a is 1 (referenced by the first element of its HashTable), this zval will not be destroyed by GC, and this part of the memory will be leaked.

What is particularly important to point out here is that PHP stores variable symbols through a symbol table (Symbol Table). There is a global symbol table, and each complex type such as an array or object has its own symbol table. Therefore, in the above code, a and a[0] are two symbols, but a is stored in the global symbol table, and a[0] is stored in the symbol table of the array itself, and here a and a[0] refer to the same zval (of course the symbol a was later destroyed). I hope readers will pay attention to distinguishing the relationship between symbol (Symbol) and zval.

When PHP is only used for dynamic page scripts, this leakage may not be very important, because the life cycle of dynamic page scripts is very short, and PHP will ensure that all its resources are released when the script is executed. However, PHP has developed to the point where it is no longer just used as a dynamic page script. If PHP is used in scenarios with a long life cycle, such as automated test scripts or deamon processes, the memory leaks accumulated after many cycles may be It will be serious. This is not sensational. A company I once interned with used a deamon process written in PHP to interact with the data storage server.

Due to this flaw in Reference Counting, PHP5.3 improved the garbage collection algorithm.

Garbage collection algorithm in PHP5.3 - Concurrent Cycle Collection in Reference Counted Systems

The garbage collection algorithm of PHP5.3 is still based on reference counting, but it no longer uses simple counting as the recycling criterion, but uses a synchronous recycling algorithm. This algorithm was proposed by IBM engineers in the paper Concurrent Cycle Collection in Reference Counted Systems.

This algorithm is quite complex. I think everyone can tell from the 29 pages of the paper, so I do not intend (and do not have the ability) to fully discuss this algorithm. Interested friends can read the paper mentioned above ( Highly recommended, the paper is brilliant).

I can only briefly describe the basic idea of ​​this algorithm here.

First, PHP will allocate a fixed-size "root buffer". This buffer is used to store a fixed number of zvals. The default number is 10,000. If you need to modify it, you need to modify the source code Zend/zend_gc.c The constant GC_ROOT_BUFFER_MAX_ENTRIES and then recompile.

From the above we can know that if a zval has a reference, it will either be referenced by a symbol in the global symbol table or by a symbol in other zvals that represent complex types. So there are some possible roots in zval. Here we will not discuss how PHP discovers these possible roots. This is a very complex problem. In short, PHP has a way to discover these possible root zvals and put them into the root buffer.

When the root buffer is full, PHP will perform garbage collection. The recycling algorithm is as follows:

1. For the root zval in each root buffer, traverse all zvals that can be traversed according to the depth-first traversal algorithm, and decrement the refcount of each zval by 1. At the same time, in order to avoid decrementing the same zval by 1 multiple times (because Different roots may traverse the same zval). Each time a zval is decremented by 1, it is marked as "decremented".

2. Traverse the root zval in each buffer depth-first again. If the refcount of a zval is not 0, add 1 to it, otherwise keep it at 0.

3. Clear all roots in the root buffer (note that these zvals are cleared from the buffer instead of destroying them), then destroy all zvals with a refcount of 0, and reclaim their memory.

It’s okay if you don’t fully understand it. Just remember that the garbage collection algorithm of PHP5.3 has the following characteristics:

1. The recycling cycle does not start every time the refcount decreases. Garbage collection only starts after the root buffer is full.

2. Can solve the circular reference problem.

3. Memory leaks can always be kept below a threshold.

Performance comparison of garbage collection algorithms between PHP5.2 and PHP5.3

Due to my current limitations, I will not redesign the experiment, but directly quote the experiment in the PHP Manual. For a performance comparison between the two, please refer to the relevant chapters in the PHP Manual: http://www.php .net/manual/en/features.gc.performance-considerations.php.

The first is the memory leak test. The experimental code and test result diagram in the PHP Manual are directly quoted below:

class Foo
{
    public $var = '3.1415962654';
}

$baseMemory = memory_get_usage();

for ( $i = 0; $i {
    $a = new Foo;
    $a->self = $a;
    if ( $i % 500 === 0 )
    {
        echo sprintf( '%8d: ', $i ), memory_get_usage() - $baseMemory, "n";
    }
}
?>

class Foo
{
    public $var = '3.1415962654';
}

$baseMemory = memory_get_usage();

for ( $i = 0; $i {
    $a = new Foo;
    $a->self = $a;
    if ( $i % 500 === 0 )
    {
        echo sprintf( '%8d: ', $i ), memory_get_usage() - $baseMemory, "n";
    }
}
?>

可以看到在可能引发累积性内存泄露的场景下，PHP5.2发生持续累积性内存泄露，而PHP5.3则总能将内存泄露控制在一个阈值以下（与根缓冲区大小有关）。

另外是关于性能方面的对比：

class Foo
{
    public $var = '3.1415962654';
}

for ( $i = 0; $i {
    $a = new Foo;
    $a->self = $a;
}

echo memory_get_peak_usage(), "n";
?>

class Foo
{
    public $var = '3.1415962654';
}

for ( $i = 0; $i {
    $a = new Foo;
    $a->self = $a;
}

echo memory_get_peak_usage(), "n";
?>

这个脚本执行1000000次循环，使得延迟时间足够进行对比，然后使用CLI方式分别在打开内存回收和关闭内存回收的的情况下运行此脚本：

time php -dzend.enable_gc=0 -dmemory_limit=-1 -n example2.php
# and
time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php

time php -dzend.enable_gc=0 -dmemory_limit=-1 -n example2.php
# and
time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php

在我的机器环境下，运行时间分别为6.4s和7.2s，可以看到PHP5.3的垃圾回收机制会慢一些，但是影响并不大。

与垃圾回收算法相关的PHP配置

可以通过修改php.ini中的zend.enable_gc来打开或关闭PHP的垃圾回收机制，也可以通过调用gc_enable( )或gc_disable( )打开或关闭PHP的垃圾回收机制。在PHP5.3中即使关闭了垃圾回收机制，PHP仍然会记录可能根到根缓冲区，只是当根缓冲区满额时，PHP不会自动运行垃圾回收，当然，任何时候您都可以通过手工调用gc_collect_cycles( )函数强制执行内存回收。

本文基于署名-非商业性使用 3.0许可协议发布，欢迎转载，演绎，但是必须保留本文的署名张洋

（包含链接），且不得用户商业目的。

http://www.bkjia.com/PHPjc/371631.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/371631.htmlTechArticle

前言：PHP是一门托管型语言，在PHP编程中程序员不需要手工处理内存资源的分配与释放（使用C编写PHP或Zend扩展除外），这就意味着PHP本身...