RE: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_execute.c
| From: | Andi Gutmans | Date: | Fri, 20 Aug 2004 01:31:57 +0000 |
| Subject: | RE: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_execute.c | ||
| References: | 1 | Groups: | php.internals php.zend-engine.cvs |
| Request: | Send a blank email to internals+get-12279@lists.php.net to get a copy of this message | ||
Yes we might.
But first we have to check this is stable and secondly I have to do some research and see if there are other reasons the opcodes might not be re-entrant.
Andi
At 02:32 AM 8/20/2004 +0100, Steph wrote:
Not clearer to me :) If this was a big reason for reverting __toString() for 5.0.0, does it mean we're going to see it again soon as a result of this change? -----Original Message----- From: Andi Gutmans [mailto:andi@zend.com] Sent: 20 August 2004 00:53 To: Sterling Hughes Cc: Andi Gutmans; zend-engine-cvs@lists.php.net; internals@lists.php.net Subject: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_execute.c Hey, No it's actually a bigger change than just being in the opcode as opposed to the end of the opcode. Actually, it would take least one more opcode execution for the garbage to run. This is the reason why destructors or resource dtor's would not always be called right away. Now if the garbage wouldn't fill up then it could actually take even more time for these values to be collected. Worse, it also impacted re-entrancy because if an opcode would call another opcode then the two garbages could get mixed up and we might free garbage a tad bit too early (that was a big reason for me reverting __toString() for 5.0.0). The new implementation make sure that every single opcode cleans up after itself. So it's more verbose and requires to make sure every opcode does the right thing but the end result is better. Hope all this garbage is a bit clearer now :) Andi At 02:20 PM 8/19/2004 -0700, Sterling Hughes wrote:Andi Gutmans wrote:the FREE_OPSure, but it was at the end of the opcode, this moves it intoNot exactly because clean_garbage() was also inline.macro, as opposed to marking (+ sweeping ;) or something else,right? I'mnot against that change in any respect, as I mentioned, I'm abig +1, justchecking... -Sterlingbugs resultingAt 01:28 PM 8/19/2004 -0700, Sterling Hughes wrote:Andi Gutmans wrote:andi Thu Aug 19 16:03:06 2004 EDTModified files: /ZendEngine2 zend_compile.h zend_execute.c Log: - Stop using garbage. Please let me know if you find any-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php- of this patch (very likely). (Dmitry, Andi)This patch seems to move destruction inline? -Sterling -- Zend Engine CVS Mailing List (http://cvs.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php