Home >Backend Development >PHP Tutorial >A brief discussion of PHP source code 33: Basics of the new garbage collection mechanism (Garbage Collection) added in PHP5.3
This article mainly introduces the basics of PHP source code thirty-three: the newly added garbage collection mechanism (Garbage Collection) of PHP5.3. It has a certain reference value. Now I share it with you. Friends in need can refer to it. Let’s talk about
33 of PHP source code: The basics of the new garbage collection mechanism (Garbage Collection) in PHP5.3
The garbage collection mechanism is newly added in PHP5.3, which is said to be very advanced. That said seduced me to see its advanced implementation.
For the official documentation, please click Garbage Collection
Chinese version address: http://docs.php.net/manual/zh/features.gc.php
[Embedding method of garbage collection mechanism]## The #zend_gc.h file is referenced at line 749 of zend.h: #include "zend_gc.h"
Thus replacing the ALLOC_ZVAL and other macros in the zend_alloc.h file referenced at line 237
zend/zend_gc. h file starts at line 202
/* The following macroses override macroses from zend_alloc.h */#undef ALLOC_ZVAL#define ALLOC_ZVAL(z) \ do {\ (z) = (zval*)emalloc(sizeof(zval_gc_info));\ GC_ZVAL_INIT(z);\ } while (0)The definition of ALLOC_ZVAL macro in zend_alloc.h is to allocate the memory space of a zval structure. The new ALLOC_ZVAL macro allocates a zval_gc_info structure macro. The structure of zval_gc_info is as follows:
zend/zend_gc.h file starts at line 91:
typedef struct _zval_gc_info { zval z; union { gc_root_buffer *buffered; struct _zval_gc_info *next; } u;} zval_gc_info;The first member of zval_gc_info is the zval structure, which ensures that it is aligned with the beginning of the memory allocated with the zval variable , so that it can be used as a zval when the zval_gc_info type pointer is cast. The gc_root_buffer, etc. will be introduced later in the structure and implementation. It defines the cache structure of the PHP garbage collection mechanism. GC_ZVAL_INIT is used to initialize zval_gc_info that replaces zval. It will set the buffered field of member u in zval_gc_info to NULL. This field will only have a value when it is put into the garbage collection buffer, otherwise it will always be NULL. Since all variables in PHP exist in the form of zval variables, zval_gc_info is used here to replace zval, thereby successfully integrating the garbage collection mechanism in the original system.
This feels a bit like object-oriented polymorphism.
Node structure:
typedef struct _gc_root_buffer { struct _gc_root_buffer *prev;/* double-linked list */ struct _gc_root_buffer *next; zend_object_handle handle;/* must be 0 for zval */ union { zval *pz; zend_object_handlers *handlers; } u;} gc_root_buffer;Obviously (see comments, although there are very few comments in PHP, some are purely tangled comments) , which is a doubly linked list. The pz variable in the union is obviously the polymorphic zval_gc_info structure defined before, so its current node pointer in the linked list can be passed ((zval_gc_info*)(pz))->u .buffered, but looking at the source code, this calling method is used in many places, why not create a new macro? Is it because I am afraid of having too many macros? No, PHP is famous for having many macros, and there are many macros that have more nested macros than this one. don't know. In addition, handle and other structures are specifically targeted at object variables. The buffer is in a global variable. Like the global variables of other modules, gc also has its own global variable access macro GC_G(v). Similarly, the global variable access macro is different under ZTS or not. realization.
The global variables defined in zend_gc.h are as follows:
typedef struct _zend_gc_globals { zend_bool gc_enabled;/* 是否开启垃圾收集机制 */ zend_bool gc_active;/* 是否正在进行 */ gc_root_buffer *buf;/* 预分配的缓冲区数组,默认为10000(preallocated arrays of buffers) */ gc_root_buffer roots;/* 列表的根结点(list of possible roots of cycles) */ gc_root_buffer *unused;/* 没有使用过的缓冲区列表(list of unused buffers) */ gc_root_buffer *first_unused;/* 指向第一个没有使用过的缓冲区结点(pointer to first unused buffer) */ gc_root_buffer *last_unused;/* 指向最后一个没有使用过的缓冲区结点,此处为标记结束用(pointer to last unused buffer) */ zval_gc_info *zval_to_free;/* 将要释放的zval变量的临时列表(temporaryt list of zvals to free) */ zval_gc_info *free_list;/* 临时变量,需要释放的列表开头 */ zval_gc_info *next_to_free;/* 临时变量,下一个将要释放的变量位置*/ zend_uint gc_runs;/* gc运行的次数统计 */ zend_uint collected; /* gc中垃圾的个数 */ // 省略...[Color marking in the garbage collection mechanism]
#define GC_COLOR 0x03 #define GC_BLACK 0x00#define GC_WHITE 0x01#define GC_GREY 0x02#define GC_PURPLE 0x03 #define GC_ADDRESS(v) \ ((gc_root_buffer*)(((zend_uintptr_t)(v)) & ~GC_COLOR))#define GC_SET_ADDRESS(v, a) \ (v) = ((gc_root_buffer*)((((zend_uintptr_t)(v)) & GC_COLOR) | ((zend_uintptr_t)(a))))#define GC_GET_COLOR(v) \ (((zend_uintptr_t)(v)) & GC_COLOR)#define GC_SET_COLOR(v, c) \ (v) = ((gc_root_buffer*)((((zend_uintptr_t)(v)) & ~GC_COLOR) | (c)))#define GC_SET_BLACK(v) \ (v) = ((gc_root_buffer*)(((zend_uintptr_t)(v)) & ~GC_COLOR))#define GC_SET_PURPLE(v) \ (v) = ((gc_root_buffer*)(((zend_uintptr_t)(v)) | GC_PURPLE))In PHP's memory management, we have also seen similar The last bit serves as some type of marking method. Here, the last two digits of the memory allocation are used as the color mark of the entire structure. Among them,
white means garbage
purple means it has been put into the buffer
gray means that a refcount minus one operation has been performed
black is the default color, normal
PHP3.0 version is in the zend/zend.h file, which is defined as follows:
struct _zval_struct { /* Variable information */ zvalue_value value;/* value */ zend_uint refcount__gc; zend_uchar type;/* active type */ zend_uchar is_ref__gc;};In versions before php3.0, such as php5.2.9 version, it is in the zend/zend.h file , its definition is as follows:
struct _zval_struct { /* Variable information */ zvalue_value value;/* value */ zend_uint refcount; zend_uchar type;/* active type */ zend_uchar is_ref;};The above is the entire content of this article. I hope it will be helpful to everyone's study. For more related content, please pay attention to the PHP Chinese website! Related recommendations:
A brief discussion on PHP source code 32: emalloc/efree layer and heap layer in PHP memory pool
A brief discussion on PHP source code 31: The basics of the heap layer in the PHP memory pool
A brief discussion on PHP source code 30: PHP memory pool Storage layer in
The above is the detailed content of A brief discussion of PHP source code 33: Basics of the new garbage collection mechanism (Garbage Collection) added in PHP5.3. For more information, please follow other related articles on the PHP Chinese website!