Re: Zend GC Recursion Elimination

Rasmus, On Fri, Jun 14, 2013 at 2:35 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > On 06/14/2013 11:04 AM, Anthony Ferrara wrote: > > When you run that on current master, you get a segfault stemming from the > > zval_mark_grey() GC function. > > This segfault, or at least a segfault in zval_mark_grey(), has been > reported a couple of times: > > https://bugs.php.net/64868 > https://bugs.php.net/64827 > https://bugs.php.net/61968 A quick look at those bugs appears to be a different cause. The backtrace is VERY different from the segfault I got: #0 0x0000000000587122 in zval_mark_grey (pz=0x7ffff1a7ce38) at /home/ircmaxell/php-src2/Zend/zend_gc.c:374 #1 0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at /home/ircmaxell/php-src2/Zend/zend_gc.c:432 #2 0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at /home/ircmaxell/php-src2/Zend/zend_gc.c:432 #3 0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at /home/ircmaxell/php-src2/Zend/zend_gc.c:432 **SNIP** #196320 0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at /home/ircmaxell/php-src2/Zend/zend_gc.c:432 #196321 0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at /home/ircmaxell/php-src2/Zend/zend_gc.c:432 #196322 0x0000000000588105 in gc_mark_roots () at /home/ircmaxell/php-src2/Zend/zend_gc.c:501 #196323 gc_collect_cycles () at /home/ircmaxell/php-src2/Zend/zend_gc.c:795 #196324 0x0000000000588359 in gc_zval_possible_root (zv=<value optimized out>) at /home/ircmaxell/php-src2/Zend/zend_gc.c:166 ... So this is due to DEEP recursion (but not infinite) in zval_mark_grey, where those 3 bugs (at least the two with backtraces) appear to be more illegal memory access as opposed to unbound recursion... At least on the surface... > > So not a huge win overall, but can be significant in cases... > > > > What do you think? Is this worth pursuing further? is there a case I'm > > missing, or some other reason we shouldn't do this? > > Since the reduced stack usage is likely to reduce the chances of hitting > this segfault, which if it is the same one as in the bug reports, it is > happening in the wild, then it is very much worthwhile to pursue this. > > Well, again, this segfault is an extreme edge-case. I'm not sure if it will work, but I will tag into one of those tickets, and see if this refactor does indeed clean it up (or not)... Thanks Anthony