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
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
|
