Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_execute.c
| From: | Andi Gutmans | Date: | Thu, 19 Aug 2004 23:52:56 +0000 |
| Subject: | Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.h zend_execute.c | ||
| References: | 1 2 3 4 | Groups: | php.internals php.zend-engine.cvs |
| Request: | Send a blank email to internals+get-12275@lists.php.net to get a copy of this message | ||
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:Not exactly because clean_garbage() was also inline.Sure, but it was at the end of the opcode, this moves it into the FREE_OP macro, as opposed to marking (+ sweeping ;) or something else, right? I'm not against that change in any respect, as I mentioned, I'm a big +1, just checking... -SterlingAt 01:28 PM 8/19/2004 -0700, Sterling Hughes wrote:Andi Gutmans wrote: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.phpandi 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 bugs resulting - of this patch (very likely). (Dmitry, Andi)