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...
-Sterling
At 01:28 PM 8/19/2004 -0700, Sterling Hughes wrote:
Andi Gutmans wrote:
andi Thu Aug 19 16:03:06 2004 EDT
Modified 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)
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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
