From b942032e4f1a84b017ad80b49015b960828c6517 Mon Sep 17 00:00:00 2001 From: Hannes Magnusson Date: Sun, 17 Jan 2010 21:27:09 +0000 Subject: [PATCH] - More markup upgrades - Remove unrelated info (that paper link however is interesting) git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@293666 c90b9560-bf6c-de11-be94-00142212c4b1 --- features/gc.xml | 115 +++++++++++++++++++++--------------------------- 1 file changed, 49 insertions(+), 66 deletions(-) diff --git a/features/gc.xml b/features/gc.xml index 6faea61d46..0f24416133 100644 --- a/features/gc.xml +++ b/features/gc.xml @@ -5,8 +5,7 @@ This section explains the merits of the new Garbage Collection (also known - as GC) mechanism that is part of PHP 5.3. This was originally written as a - three part column for php|architect. + as GC) mechanism that is part of PHP 5.3. @@ -342,18 +341,11 @@ a: (refcount=2, is_ref=1)=array ( Collecting Cycles - Traditionally, reference counting memory mechanisms, such as that used by - PHP, fail to address those circular reference memory leaks. Back in 2007, - while looking into this issue, I was pointed to a paper by David F. Bacon - and V.T. Rajan titled "Concurrent Cycle - Collection in Reference Counted Systems". Although the paper was - written with Java in mind, I started to play around with it to see if it - was feasible to implement the synchronous algorithm, as outlined in the - paper, in PHP. At that moment, I didn't have a lot of time, but along came - the Google Summer of Code project and we put forward the implementation of - this paper as one of our ideas. Yiduo (David) Wang picked up this idea and - started hacking on the first version as part of the Summer of Code - project. + Traditionally, reference counting memory mechanisms, such as that used + previously by PHP, fail to address circular reference memory leaks. + As of 5.3.0 PHP however implements the synchronous algorithm from the + Concurrent Cycle Collection in Reference Counted Systems + paper which addresses that issue. A full explanation of how the algorithm works would be slightly beyond the @@ -380,7 +372,7 @@ a: (refcount=2, is_ref=1)=array ( (zvals) in the "root buffer" (marking them "purple"). It also makes sure that each possible garbage root ends up in the buffer only once. Only when the root buffer is full does the collection mechanism start for all the - different zvals inside. See step A in the figure. + different zvals inside. See step A in the figure above. In step B, the algorithm runs a depth-first search on all possible roots @@ -451,11 +443,6 @@ a: (refcount=2, is_ref=1)=array ( then leaves an empty buffer so that there is more space for storing possible roots while the cycle collecting mechanism is turned off. - - In this section, we saw how the garbage collection mechanism works and - how it is integrated into PHP. In the third and final section, - we will look at performance considerations and benchmarks. - @@ -488,15 +475,9 @@ a: (refcount=2, is_ref=1)=array ( itself uses when starting up. - - Comparison of memory usage between PHP 5.2 and PHP 5.3 - - - - - - - + + Memory usage example + ]]> - + + + Comparison of memory usage between PHP 5.2 and PHP 5.3 + + + + + In this very academic example, we are creating an object in which a - property is set to point back to the object itself. When the $a variable + property is set to point back to the object itself. When the $a variable in the script is re-assigned in the next iteration of the loop, a memory leak would typically occur. In this case, two zval-containers are leaked (the object zval, and the property zval), but only one possible root is @@ -549,7 +537,9 @@ for ( $i = 0; $i <= 100000; $i++ ) second script is here: - + + GC performance influences + ]]> - + + We will run this script two times, once with the @@ -574,13 +565,16 @@ echo memory_get_peak_usage(), "\n"; turned off: - -time ~/dev/php/php-5.3dev/sapi/cli/php -dzend.enable_gc=0 \ - -dmemory_limit=-1 -n Listing1.php + + Running the above script + + +time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php +]]> + + On my machine, the first command seems to take consistently about 10.7 @@ -594,25 +588,6 @@ time ~/dev/php/php-5.3dev/sapi/cli/php -dzend.enable_gc=1 \ capabilities save more and more memory as more circular references are found during script execution. - - Let's now have a look at non-academic situation. I first started looking - for circular reference collecting algorithms when I found out that while - running the tests of the eZ Components' Template component with PHPUnit, - I ended up swapping a lot, rendering my machine useless in the process. - In order to do some benchmarks for this article, I re-ran those same - tests with an empty php.ini file to disable the overhead and memory - allocation that Xdebug was creating while doing code-coverage analysis. - - - Memory consumption dropped 95% from 1.7Gb to 75Mb, and the runtime as - reported by PHPUnit increased from 2:17 for the non-GC enabled run to - 2:33 for the GC enabled run, an increase of about 12%. However, with the - non-GC enabled run, PHP sat there doing "nothing" for almost 15 seconds. - Upon investigation with the Unix debugger, GDB, I noticed that those 15 - seconds were all spent on freeing memory allocated for objects inside - the PHP runtime. The actual time that the script ran was about the same - in the end. - @@ -627,12 +602,17 @@ time ~/dev/php/php-5.3dev/sapi/cli/php -dzend.enable_gc=1 \ sequence should do the trick: - + + Recompiling PHP to enable GC benchmarking + + +]]> + + When you run the above example code again with the newly built PHP @@ -640,7 +620,10 @@ make execution: - + + GC statistics + + +]]> + + The most informative statistics are displayed in the first block. You @@ -667,9 +652,7 @@ ZOBJ 28506264 1527980 677581 1025731 Conclusion - In this third and final installment, we had a quick look at the - performance implications of the garbage collection mechanism that is now - part of PHP 5.3. In general, it will only cause a slowdown when the + In general the garbage collector in PHP will only cause a slowdown when the cycle collecting algorithm actually runs, whereas in normal (smaller) scripts there should be no performance hit at all. @@ -681,7 +664,7 @@ ZOBJ 28506264 1527980 677581 1025731 The benefits are most apparent for longer-running scripts, such as - lengthy test suites or daemon scripts. Also, for PHP-GTK applications + lengthy test suites or daemon scripts. Also, for PHP-GTK applications that generally tend to run longer than scripts for the Web, the new mechanism should make quite a bit of a difference regarding memory leaks creeping in over time.