Re: Reference cycle collector patch

php.internals

Tony Bibbs

18 years ago
For the untrained eye, would this then fix these bugs? http://bugs.php.net/bug.php?id=33595 http://bugs.php.net/bug.php?id=33487 --Tony ----- Original Message ---- From: David Wang <planetbeing@gmail.com> To: internals@lists.php.net Sent: Monday, October 8, 2007 2:12:31 AM Subject: [PHP-DEV] Reference cycle collector patch Hey all, Now that macros for manipulating refcount and is_ref have been implemented, I’m ready to submit patches for the GC. I know you all have been waiting for this for a long time ☺. I have made two sets of patches, one for HEAD and one for PHP_5_3 (note that I had to rearrange the order of definitions and #includes in zend.h to get around a recursive dependency problem): http://zoo.cs.yale.edu/~yw226/gc/gc6.diff.txt http://zoo.cs.yale.edu/~yw226/gc/gc5_3.diff.txt After applying those, these two files should be placed in the Zend subdirectory: http://zoo.cs.yale.edu/~yw226/gc/zend_gc.c http://zoo.cs.yale.edu/~yw226/gc/zend_gc.h For those who were following the progress of the GC through the incubator SVN, the GC implemented with these patches is DIFFERENT than the one currently in the SVN tree. They are from an “experimental” branch that I believed was more tolerant of the zval juggling PHP and its extensions sometimes like to do. It turned out to be very successful, but I hadn’t bothered remerging it. I highly recommend these two patches in addition (but they are optional for GC functioning): http://zoo.cs.yale.edu/~yw226/gc/alwaysinline6.diff.txt http://zoo.cs.yale.edu/~yw226/gc/alwaysinline5_3.diff.txt These are meant to be applied after the previous patches. These simply change all the inline functions in the Zend engine to “always_inline”. Zend object files can become seriously oversized and this makes the compiler silently ignore the inline keyword. Changing this to always_inline (defined in zend.h) forces the compiler to inline the function or at least give a warning if it cannot. The reason I bring up the issue here is that my patch is known to sometimes push object files that were just under the internal compiler limit over the edge and make the compiler refuse to inline. This has the effect of making the whole Zend engine disproportionately slower. Anyway, please try these out and tell me how it goes! David P.S. This patch has the GC enabled by default. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Alexey Zakhlestin

18 years ago
On 10/8/07, Tony Bibbs <tony@tonybibbs.com> wrote:
> For the untrained eye, would this then fix these bugs? > > http://bugs.php.net/bug.php?id=33595
yes
> http://bugs.php.net/bug.php?id=33487
no by the way, 33487 is not really a bug if it is stated this way. the proper bug description for 33487 would be: "there is no mechanism in zend_object_storage to free unused memory during script execution"
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

David

18 years ago
On 10/8/07, Alexey Zakhlestin <indeyets@gmail.com> wrote:
> by the way, 33487 is not really a bug if it is stated this way. > the proper bug description for 33487 would be: > "there is no mechanism in zend_object_storage to free unused memory > during script execution"
Yeah, it fixes the issue in that this behavior isn't a problem anymore, but there is no reference counting-like promptness in freeing memory that is occupied by garbage cycles. Actually, I did create a userland function that manually frees that memory (should you want to). It basically calls the garbage collection routine manually: gc_collect_cycles(). You would call that function after $t->doNothing(); and you would get the expected result. David