This chapter is from the book
This chapter is from the book
This chapter is from the book
Reference Counting
Careful memory allocation and freeing is vital to the long term performance of a multirequest process like PHP, but it's only half the picture. In order for a server that handles thousands of hits per second to function efficiently, each request needs to use as little memory as possible and perform the bare minimum amount of unnecessary data copying. Consider the following PHP code snippet:
<?php
$a = 'Hello World';
$b = $a;
unset($a);
?>
After the first call, a single variable has been created, and a 12 byte block of memory has been assigned to it holding the string 'Hello World' along with a trailing NULL. Now look at the next two lines: $b is set to the same value as $a, and then $a is unset (freed).
If PHP treated every variable assignment as a reason to copy variable contents, an extra 12 bytes would need to be copied for the duplicated string and additional processor load would be consumed during the data copy. This action starts to look ridiculous when the third line has come along and the original variable is unset making the duplication of data completely unnecessary. Now take that one further and imagine what could happen when the contents of a 10MB file are loaded into two variables. That could take up 20MB where 10 would have been sufficient. Would the engine waste so much time and memory on such a useless endeavor?
You know PHP is smarter than that.
Remember that variable names and their values are actually two different concepts within the engine. The value itself is a nameless zval* holding, in this case, a string value. It was assigned to the variable $a using zend _hash_add(). What if two variable names could point to the same value?
{
zval *helloval;
MAKE_STD_ZVAL(helloval);
ZVAL_STRING(helloval, "Hello World", 1);
zend_hash_add(EG(active_symbol_table), "a", sizeof("a"),
&helloval, sizeof(zval*), NULL);
zend_hash_add(EG(active_symbol_table), "b", sizeof("b"),
&helloval, sizeof(zval*), NULL);
}
At this point you could actually inspect either $a or $b and see that they both contain the string "Hello World". Unfortunately, you then come to the third line: unset($a);. In this situation, unset() doesn't know that the data pointed to by the $a variable is also in use by another one so it just frees the memory blindly. Any subsequent accesses to $b will be looking at already freed memory space and cause the engine to crash. Hint: You don't want to crash the engine.
This is solved by the third of a zval's four members: refcount. When a variable is first created and set, its refcount is initialized to 1 because it's assumed to only be in use by the variable it is being created for. When your code snippet gets around to assigning helloval to $b, it needs to increase that refcount to 2 because the value is now "referenced" by two variables:
{
zval *helloval;
MAKE_STD_ZVAL(helloval);
ZVAL_STRING(helloval, "Hello World", 1);
zend_hash_add(EG(active_symbol_table), "a", sizeof("a"),
&helloval, sizeof(zval*), NULL);
ZVAL_ADDREF(helloval);
zend_hash_add(EG(active_symbol_table), "b", sizeof("b"),
&helloval, sizeof(zval*), NULL);
}
Now when unset() deletes the $a copy of the variable, it can see from the refcount parameter that someone else is interested in that data and it should actually just decrement the refcount and otherwise leave it alone.
Copy on Write
Saving memory through refcounting is a great idea, but what happens when you only want to change one of those variables? Consider this code snippet:
<?php
$a = 1;
$b = $a;
$b += 5;
?>
Looking at the logic flow you would of course expect $a to still equal 1, and $b to now be 6. At this point you also know that Zend is doing its best to save memory by having $a and $b refer to the same zval after the second line, so what happens when the third line is reached and $b must be changed?
The answer is that Zend looks at refcount, sees that it's greater than one and separates it. Separation in the Zend engine is the process of destroying a reference pair and is the opposite of the process you just saw:
zval *get_var_and_separate(char *varname, int varname_len TSRMLS_DC)
{
zval **varval, *varcopy;
if (zend_hash_find(EG(active_symbol_table),
varname, varname_len + 1, (void**)&varval) == FAILURE) {
/* Variable doesn't actually exist — fail out */
return NULL;
}
if ((*varval)->refcount < 2) {
/* varname is the only actual reference,
* no separating to do
*/
return *varval;
}
/* Otherwise, make a copy of the zval* value */
MAKE_STD_ZVAL(varcopy);
varcopy = *varval;
/* Duplicate any allocated structures within the zval* */
zval_copy_ctor(varcopy);
/* Remove the old version of varname
* This will decrease the refcount of varval in the process
*/
zend_hash_del(EG(active_symbol_table), varname, varname_len + 1);
/* Initialize the reference count of the
* newly created value and attach it to
* the varname variable
*/
varcopy->refcount = 1;
varcopy->is_ref = 0;
zend_hash_add(EG(active_symbol_table), varname, varname_len + 1,
&varcopy, sizeof(zval*), NULL);
/* Return the new zval* */
return varcopy;
}
Now that the engine has a zval* that it knows is only owned by the $b variable, it can convert it to a long and increment it by 5 according to the script's request.
Change on Write
The concept of reference counting also creates a new possibility for data manipulation in the form of what userspace scripters actually think of in terms of "referencing". Consider the following snippet of userspace code:
<?php
$a = 1;
$b = &$a;
$b += 5;
?>
Being experienced in the ways of PHP code, you'll instinctively recognize that the value of $a will now be 6 even though it was initialized to 1 and never (directly) changed. This happens because when the engine goes to increment the value of $b by 5, it notices that $b is a reference to $a and says, "It's okay for me to change the value without separating it, because I want all reference variables to see the change."
But how does the engine know? Simple, it looks at the fourth and final element of the zval struct: is_ref. This is just a simple on/off bit value that defines whether the value is, in fact, part of a userspace-style reference set. In the previous code snippet, when the first line is executed, the value created for $a gets a refcount of 1, and an is_ref value of 0 because its only owned by one variable ($a), and no other variables have a change on write reference to it. At the second line, the refcount element of this value is incremented to 2 as before, except that this time, because the script included an ampersand to indicate full-reference, the is_ref element is set to 1.
Finally, at the third line, the engine once again fetches the value associated with $b and checks if separation is necessary. This time the value is not separated because of a check not included earlier. Here's the refcount check portion of get_var_and_separate() again, with an extra condition:
if ((*varval)->is_ref || (*varval)->refcount < 2) {
/* varname is the only actual reference,
* or it's a full reference to other variables
* either way: no separating to be done
*/
return *varval;
}
This time, even though the refcount is 2, the separation process is short-circuited by the fact that this value is a full reference. The engine can freely modify it with no concern about the values of other variables appearing to change magically on their own.
Separation Anxiety
With all this copying and referencing, there are a couple of combinations of events that can't be handled by clever manipulation of is_ref and refcount. Consider this block of PHP code:
<?php
$a = 1;
$b = $a;
$c = &$a;
?>
Here you have a single value that needs to be associated with three different variables, two in a change-on-write full reference pair, and the third in a separable copy-on-write context. Using just is_ref and refcount to describe this relationship, what values will work?
The answer is: none. In this case, the value must be duplicated into two discrete zval*s, even though both will contain the exact same data (see Figure 3.2).
)
Figure 3.2 Forced separation on reference.
Similarly, the following code block will cause the same conflict and force the value to separate into a copy (see Figure 3.3).
)
Figure 3.3 Forced separation on copy.
<?php
$a = 1;
$b = &$a;
$c = $a;
?>
Notice here that in both cases here, $b is associated with the original zval object because at the time separation occurs, the engine doesn't know the name of the third variable involved in the operation.