Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:30880 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65073 invoked by uid 1010); 13 Jul 2007 04:06:26 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 65058 invoked from network); 13 Jul 2007 04:06:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jul 2007 04:06:26 -0000 Authentication-Results: pb1.pair.com header.from=andi@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=andi@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender) X-PHP-List-Original-Sender: andi@zend.com X-Host-Fingerprint: 63.205.162.114 unknown Windows 2000 SP4, XP SP1 Received: from [63.205.162.114] ([63.205.162.114:39152] helo=us-ex1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3D/A1-35224-04AF6964 for ; Fri, 13 Jul 2007 00:06:24 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 12 Jul 2007 21:06:14 -0700 Message-ID: <698DE66518E7CA45812BD18E807866CE647F04@us-ex1.zend.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PHP-DEV] Mid-term Update for Cycle Collector (Google Summer of Code Project) Thread-Index: AcfE5PQV/rLFe3aURSCrywNe+GJWxAAB7aYgAAVizFA= References: <46969CCA.3010608@zend.com> <000901c7c4e3$2b803030$82809090$@com> <4696C77B.2060005@php.net> <000501c7c4ee$0acff590$206fe0b0$@com> To: "David" , "Scott MacVicar" Cc: "Stas Malyshev" , "Sebastian Bergmann" , Subject: RE: [PHP-DEV] Mid-term Update for Cycle Collector (Google Summer of Code Project) From: andi@zend.com ("Andi Gutmans") Hi David, Isn't finding cycles an NP-complete problem? :) How can you know there are no cycles without actually looking for them? It would definitely be nice to be able to turn this feature on/off at runtime. The majority of pages in PHP don't require such a feature but it's a good thing for us to have (I've looked into this quite a bit in the past). As for the additional if() statements you can try and use branch prediction hinting to the compiler in order to keep the non-gc version fast. Btw, one of the challenges I found in the past is knowing which hash tables to actually traverse because some variables/hash tables in PHP are saved outside the symbol tables. Are you really successful in traversing all of them? Are you saving their addresses during allocation? If so, how do you know they are intact when you traverse? Do you start traversal only when we're supposedly in a stable state? (re-entrancy problems?) Also the additional size of zval can be quite an issue. In fact, with the whole 16bit->32bit transition we made for refcount we reduced performance. Maybe we can figure out a creative way to keep this down? Do you mind posting a patch against your baseline to make it easier for us to look at your work? This can end up being a good thing if we manage to make it work well. The problem with this stuff though is that the last 5-10% is 95% of the work :) Thanks for the effort!=20 Andi > -----Original Message----- > From: David [mailto:planetbeing@gmail.com]=20 > Sent: Thursday, July 12, 2007 6:35 PM > To: 'Scott MacVicar' > Cc: Stas Malyshev; 'Sebastian Bergmann'; internals@lists.php.net > Subject: RE: [PHP-DEV] Mid-term Update for Cycle Collector=20 > (Google Summer of Code Project) >=20 > > Could the garabage collector be started / stopped during script=20 > > executing from a userland function? zend_gc_enable/disable() in=20 > > addition to an ini option to enable it at script startup? >=20 > Yes, that functionality can be added fairly easily. Some GC=20 > code will still have to be executed (such as the if branches=20 > that currently check whether the GC is enabled or not :-))=20 > but performance may increase slightly (since there will no=20 > longer be a function call for the GC to note down possible=20 > cycles it detects). However, a drastic performance increase=20 > will probably not be seen. It's very unlikely for the main=20 > garbage collection cycle to be run if there are no cycles=20 > present. (I can go into some technical details if you'd like). >=20 > David >=20 > -- > PHP Internals - PHP Runtime Development Mailing List To=20 > unsubscribe, visit: http://www.php.net/unsub.php >=20 >=20