In-depth analysis of PHP parameter passing principle

When writing PHP extensions, it seems that parameters (i.e., variables passed to zend_parse_parameters) do not need to be free. Example:

PHP_FUNCTION(test)
{
 char* str;
 int str_len;
 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s" ,&str , &str_len) == FAILURE) {
 RETURN_FALSE;
 }
 php_printf(str);

 // No need for free(str)
}

operating normally: test("Hello World"); // Print Hello World There is no need to worry about memory leaks in the test function here. PHP will automatically help us recycle these variables used to save parameters.

So how does php do it? To explain this problem, we still have to look at how PHP passes parameters.

EG (argument_stack) introduction To put it simply, a stack specifically used to store parameters is saved in EG in PHP, named argument_stack. Whenever a function call occurs, php will push the incoming parameters into EG (argument_stack). Once the function call ends, the EG (argument_stack) is cleared and waits for the next function call.

Regarding the struct structure and purpose of EG (argument_stack), there are some differences between the implementation of php5.2 and 5.3. This article mainly takes 5.2 as an example, and we will discuss the changes in 5.3+ later.

The above picture is a rough diagram of argument_stack in 5.2, which looks simple and clear. Among them, the top and bottom of the stack are fixed to NULL. The parameters received by the function are pushed onto the stack in order from left to right. Note that an additional long value will be pushed in at the end, indicating the number of parameters in the stack (10 in the picture above).

What are the parameters that are pushed into argument_stack? In fact, they are pointers of zval type. The zva they point to may be a CV variable, a variable with is_ref=1, or a constant number or constant string.

EG (argument_stack) is specifically implemented as zend_ptr_stack type in php5.2:

typedef struct _zend_ptr_stack {
 int top; // The number of current elements in the stack
 int max; // The maximum number of elements stored in the stack
 void **elements; // Bottom of the stack
 void * *top_element; // Top of stack
} zend_ptr_stack;

Initialize argument_stack The work of initializing argument_stack occurs before PHP processes a specific request. To be more precise, it is during the startup process of the PHP interpreter.

In the init_executor function we found the following 2 lines:

zend_ptr_stack_init(&EG(argument_stack));
zend_ptr_stack_push(&EG(argument_stack), (void *) NULL);

These two lines represent, respectively, initialization EG(ar gument_stack), Then push a NULL. Since EG is a global variable, all data in EG (argument_stack) are all 0 before zend_ptr_stack_init is actually called.

zend_ptr_stack_init implementation is very simple.

ZEND_API void zend_ptr_stack_init(zend_ptr_stack *stack)
{
 stack->top_element = stack->elements = (void **) emalloc(sizeof(void *)*PTR_STACK_BLOCK_SIZE);
 stack-& gt; max = PTR_STACK_BLOCK_SIZE; // The stack size is initialized to 64
 stack->top = 0; // The current number of elements is 0
}

Once argument_stack is initialized, it will NULL is pushed. There is no need to go into detail here, this NULL actually has no meaning.

After NULL is pushed into the stack, the actual memory distribution of the entire argument_stack is as follows:

Push parameters onto stack After pushing the first NULL, once another parameter is pushed onto the stack, the following actions will occur in argument_stack: stack->top++; *(stack->top_element++) = parameter;

Use a simple php code to illustrate the problem:

function foo( $str ){
 print_r(123);
}
foo("hello world");

The above code passes in a string constant when calling foo. Therefore, what is actually pushed onto the stack is a zval pointing to the storage "hello world". Use vld to view the compiled opcode:

line # * op fetch ext return operands
---------------------------------- --------------------------------------------------
 3 0 > ; NOP
 6 1 SEND_VAL OP1[ IS_CONST (458754) 'hello world' ]
 2 DO_FCALL 1 OP1[ IS_CONST (458752) 'foo' ]
 15 3 > RETURN OP1[ IS_CONST (0) 1 ]

SEND_VAL instruction actually does is push "hello world" into argument_stack.

int ZEND_SEND_VAL_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
 …
 zval *valptr, *value;
 value = &opline- >op1.u.constant ;
 ALLOC_ZVAL(valptr);
 INIT_PZVAL_COPY(valptr, value);
 if (!0) {
 zval_copy_ctor(valptr);
 }
 // Push to the stack, valptr points to store hello world zval
 zend_ptr_stack_push(&EG(argument_stack), valptr);
 ……
}

The argument_stack after the push is completed is:

Number of parameters As mentioned earlier, it is not actually just pushing all the parameters onto the stack. PHP will also push an additional number to represent the number of parameters. This work does not occur during the SEND_XXX command. In fact, before actually executing the function, PHP will push the number of parameters onto the stack.

Continuing to use the above example, the DO_FCALL instruction is used to call the foo function. Before calling foo, php will automatically fill in the last block of argument_stack.

static int zend_do_fcall_common_helper_SPEC(ZEND_OPCODE_HANDLER_ARGS)
{
 ……
 // Push 2 values ​​into argument_stack
 // One is the number of parameters (i.e. opline->extended_value)
 // One is the identifier NULL on the top of the stack
 zend_ptr_stack_2_push(&EG(argument_stack), (void *)(zend_uintptr_t)opline->extended_value, NULL);
 …
 if (EX(function_state).function->type == ZEND_INTERNAL_FUNCTION) {
 ……
 }
 else if (EX(function_state).function->type == ZEND_USER_FUNCTION) {
 ……
 // Call foo function
 zend_execute(EG(active_op_array) TSRMLS_CC);
 }
 else { /* ZEND_OVERLOADED_FUNCTION +/ used for The entire argument_stack of the foo call has been completed.
 Get parameters
Continuing with the example above.
Dive into the foo function and see what foo's opcode looks like.





line # * op fetch ext return operands
---------------------------------- --------------------------------------------------

Copy code

The first instruction is RECV, which is literally used to obtain the parameters in the stack. In fact, SEND_VAL and RECV have a somewhat corresponding feeling. SEND_VAL before each function call, RECV is performed inside the function. Why not say it is completely corresponding? In fact, the RECV instruction is not necessarily required. RECV is generated only when a user-defined function is called. The extension functions we write and the built-in functions that come with PHP will not have RECV.

It should be pointed out that each SEND_VAL and RECV can only process one parameter. That is to say, if there are multiple parameters in the parameter passing process, several SEND_VAL and several RECV will be generated. This leads to a very interesting topic, what is the order of passing in parameters and getting parameters?

The answer is that SEND_VAL will push the parameters onto the stack from left to right, while RECV will get the parameters from left to right.

static int ZEND_RECV_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
 ……//param takes the parameters in order along the top of the stack-->bottom of the stack
 if (zend_ptr_stack_get_arg(arg_num, (void * *) ¶m TSRMLS_CC)==FAILURE) {
 ……
 } else {
 zend_free_op free_res;
 zval **var_ptr;
 // Verify parameters
 zend_verify_arg_type((zend_function *) EG( active_op_array), arg_num, *param TSRMLS_CC);
 var_ptr = get_zval_ptr_ptr(&opline->result, EX(Ts), &free_res, BP_VAR_W);

 // Get parameters
 if (PZVAL_IS_REF(*param)) {
 zend_as sign_to_variable_reference( var_ptr, param TSRMLS_CC);
 } else {
 zend_receive(var_ptr, *param TSRMLS_CC);
 }
 }
 ZEND_VM_NEXT_OPCODE();
}

zend_assign_to_variable_reference and zend_receive will complete "getting parameters". "Getting parameters" is not easy to understand. What does it actually do?

In the final analysis, it is very simple. "Getting parameters" is to add this parameter to the "symbol table" during the execution of the current function, which specifically corresponds to EG (current_execute_data)->symbol_table. In this example, after RECV is completed, there is a symbol 'str' in the symbol_table in the function body, and its value is "hello world".

But argument_stack has not changed at all, because RECV only reads parameters and does not perform a pop operation on the stack.

Clean argument_stack The print_r inside foo is also a function call, so the stack push-->stack clear operation will also occur. Therefore the argument_stack before print_r is executed is:

After print_r is executed, argument_stack returns to the state where foo just finished RECV.

The specific process of calling print_r is not the focus of this article. What we care about is how PHP cleans up argument_stack after calling foo.

As can be seen from the do_fcall code snippet shown above, the cleaning work is completed by zend_ptr_stack_clear_multiple.

static inline void zend_ptr_stack_clear_multiple(TSRMLS_D)
{
 void **p = EG(argument_stack).top_element-2;
 // Get the number of parameters saved on the top of the stack
 int delete_count = (int)(zend_uintptr_t ) *p;
 EG(argument_stack).top -= (delete_count+2);

 // Clean up from top to bottom
 while (--delete_count>=0) {
 zval *q = *(zval * *)(--p);
 *p = NULL;
 zval_ptr_dtor(&q);
 }
 EG(argument_stack).top_element = p;
}

Pay attention to clearing the zval pointer in the stack here, zval_ptr_dtor is used. zval_ptr_dtor will decrement the refcount by 1. Once the refcount is reduced to 0, the memory area storing the variable will be truly recycled.

In the example of this article, after foo is called, the zval status of "hello world" is saved:

value "hello world"
refcount 1
type 6
is_ref 0

Since refcount is only 1, zval_ptr_dtor will actually destroy "hello world" from memory.

The memory status of argument_stack after stack elimination is:

It can be seen that the argument_stack in the above picture is the same as it was just initialized. At this point argument_stack is truly ready for the next function call.

Back to the question at the beginning of the article... Why no need for free(str)? After understanding argument_stack, you can easily understand this problem.

Because str points to the memory address where "hello world" is actually stored in zval. Assume that the extension function is as follows:

PHP_FUNCTION(test)
{
 char* str;
 int str_len;
 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s" ,&str , &str_len) == FAILURE) {
 RETURN_FALSE;
 }
 str[0] = 'H';
}

then call

$a = "hello world";
test($a);
echo $a;

will output "Hello world". Although when we call test, we do not pass the reference of $a, but the actual effect is equivalent to test(&$a).

Simply put, there is only one copy of $a in memory, whether it is in the CV array or argument_stack. zend_parse_parameters does not copy a copy of the data for function execution, and in fact it cannot do so. Therefore, when the function is completed, if $a is not used elsewhere, PHP will help us free it when cleaning up argument_stack. If it is still used by other code, it cannot be freed manually, otherwise the memory area of ​​$a will be destroyed.

Note that not every variable used in writing extension functions will be automatically recycled by PHP. So when it’s time to be free, don’t be soft:)