In-depth analysis of parameter passing principles in PHP

In-depth analysis of parameter passing principles in PHP

When writing php extensions, it seems that the parameter (that is, the variable passed to zend_parse_parameters) does 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 ); // Free (str) is not required) } Run properly: test ("Hello World"); // print Hello World. you don't have to worry about memory leakage in the test function. php will automatically help us reclaim the variables used to save parameters. How exactly does php do it? To explain this problem, we still need to see how php transmits parameters. In simple terms, the EG in php stores a stack specifically used to store parameters, called argument_stack. Whenever a function call occurs, php presses the input parameters into EG (argument_stack ). Once the function call ends, EG (argument_stack) is cleared and waits for the next function call. There are some differences between the implementation of php5.2 and 5.3 on the structure and purpose of the struct of EG (argument_stack. This article mainly takes 5.2 as an example. the changes of 5.3 + will be discussed later. It is about argument_stack in 5.2, which looks simple and clear. The stack top and bottom are fixed to NULL. Parameters received by the function are pushed to the stack sequentially from left to right. Note that an additional long value will be pushed into the stack, indicating the number of parameters in the stack (10 in total ). So what is the parameter pushed into argument_stack? Actually, they are zval type pointers. The zva they point to may be a CV variable, an is_ref = 1 variable, a constant number, or a constant string. In php5.2, EG (argument_stack) is implemented as zend_ptr_stack: Typedef struct _ zend_ptr_stack { Int top; // number of current elements in the stack Int max; // The maximum number of elements in the stack Void ** elements; // stack bottom Void ** top_element; // stack top } Zend_ptr_stack; Initializing argument_stack initializes argument_stack before php processes specific requests. more accurately, it is in the startup process of the php interpreter. In the init_executor function, we find the following two rows: Zend_ptr_stack_init (& EG (argument_stack )); Zend_ptr_stack_push (& EG (argument_stack), (void *) NULL ); These two lines represent the initialization of EG (argument_stack), followed by a NULL. Since EG is a global variable, all data in EG (argument_stack) is 0 before zend_ptr_stack_init is called. Zend_ptr_stack_init is easy to implement. 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-> max = PTR_STACK_BLOCK_SIZE; // The stack size is initialized to 64 Stack-> top = 0; // The number of current elements is 0 } Once argument_stack is initialized, it is immediately pushed into NULL. I don't need to go into it here. this NULL actually has no meaning. After NULL is added to the stack, the actual memory distribution of the entire argument_stack is as follows: After a parameter is pushed to the stack to the first NULL value, once a parameter is added to the stack, argument_stack performs the following actions: stack-> top ++; * (stack-> top_element ++) = parameter; Use a simple php code to illustrate the problem: Function foo ($ str ){ Print_r (123 ); } Foo ("hello world "); When the above code calls foo, a string constant is input. Therefore, what is actually pushed into the stack is a zval pointing to the storage of "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] What the SEND_VAL command actually does is to press "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 ); } // In the stack, valptr points to the zval that stores hello world Zend_ptr_stack_push (& EG (argument_stack), valptr ); ...... } The argument_stack after the stack entry is complete is: As mentioned above, the number of parameters does not actually end up putting all the parameters into the stack. Php will also press an additional number to indicate the number of parameters, which does not happen in the SEND_XXX command. In fact, php will import the number of parameters into the stack before the function is actually executed. Continue with the above example. the DO_FCALL command is used to call the foo function. Before calling foo, php will automatically fill in the last part of argument_stack. Static int zend_do_fcall_common_helper_SPEC (ZEND_OPCODE_HANDLER_ARGS) { ...... // Input two values in argument_stack // The number of parameters (opline-> extended_value) // One is NULL that identifies 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 the foo function Zend_execute (EG (active_op_array) TSRMLS_CC ); } Else {/* ZEND_OVERLOADED_FUNCTION */ ...... } ...... // Clear argument_stack Zend_ptr_stack_clear_multiple (TSRMLS_C ); ...... ZEND_VM_NEXT_OPCODE (); } After the number of input parameters and NULL, the entire argument_stack for foo call has been completed. Obtain the parameters and continue with the above example. Go deep into the foo function and see what the opcode of foo looks like. Line # * op fetch ext return operands --------------------------------------------------------------------------------- 3 0> RECV OP1 [IS_CONST (0) 1] 4 1 SEND_VAL OP1 [IS_CONST (5) 123] 2 DO_FCALL 1 OP1 [IS_CONST (459027) 'Print _ R'] 5 3> RETURN OP1 [IS_CONST (0) null] The first command is RECV, which is literally used to obtain parameters in the stack. Actually, SEND_VAL and RECV are similar. Before each function call, SEND_VAL performs RECV within the function. The RECV command is not required. A recv is generated only when a user-defined function is called. The extended functions we have compiled, built-in php functions, do not have RECV. Note 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. Here is an interesting topic. what is the order of input parameters and parameters? The answer is that SEND_VAL will press the stack from left to right, and get the parameters from left to right in the same way as RECV. Static int ZEND_RECV_SPEC_HANDLER (ZEND_OPCODE_HANDLER_ARGS) { ...... // Param takes the parameter order along the top of the stack --> the bottom of the stack If (zend_ptr_stack_get_arg (arg_num, (void **) & param 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 ); // Obtain parameters If (PZVAL_IS_REF (* param )){ Zend_assign_to_variable_reference (var_ptr, param TSRMLS_CC ); } Else { Zend_receive (var_ptr, * param TSRMLS_CC ); } } ZEND_VM_NEXT_OPCODE (); } Both zend_assign_to_variable_reference and zend_receive complete "GET parameters ". "Getting parameters" is not easy to understand. What exactly does it actually do? In the end, it is easy to add the parameter to the symbol table during the current function execution, which corresponds to EG (current_execute_data)-> symbol_table. In this example, after RECV is completed, the symbol_table in the function contains a symbol 'str', whose value is "hello world ". However, argument_stack does not have any changes, because RECV only reads parameters and does not generate pop-like operations on stacks. Cleanup of print_r inside argument_stackfoo is also a function call, which also produces a stack-> cleanup operation. Therefore, the argument_stack before print_r execution is: After print_r is executed, argument_stack returns to foo's RECV state. The process of calling print_r is not the focus of this article. We are concerned about how php clears argument_stack after calling foo. The do_fcall code snippet shown above shows that the cleanup 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; // Number of parameters stored 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; } Note that zval pointer in the stack is cleared here, and zval_ptr_dtor is used. Zval_ptr_dtor will reduce the refcount by 1. Once the refcount is reduced to 0, the memory area where the variable is saved will be actually recycled. In this example, after foo is called, the zval status of "hello world" is saved as follows: Value "hello world" Refcount 1 Type 6 Is_ref 0 Since refcount has only 1 left, zval_ptr_dtor will actually destroy "hello world" from the memory. The argument_stack memory status after Stack cancellation is: It can be seen that the argument_stack in is the same as that after initialization. In this case, argument_stack is ready for calling the callback function. Back to the question at the beginning of the article... why don't I need free (str? After you understand argument_stack, you can understand this problem. Because str points to the memory address that actually stores "hello world" in zval. Suppose the extended functions are 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 '; } Call $ A = "hello world "; Test ($ ); Echo $; "Hello world" is output ". Although we call test instead of passing the reference of $ a, the actual effect is equivalent to test (& $ ). In short, there is only one $ a in the memory, whether in the CV array or in argument_stack. Zend_parse_parameters does not copy a copy of data for function execution. In fact, it cannot. Therefore, after the function is completed, if $ a is used in no other place, php will help us free up argument_stack. If other code is still in use, you cannot manually free it; otherwise, the memory area of $ a will be damaged. Note that php automatically recycles not every variable used in the write extension function. So do not be soft when you are free :)