On 9/4/07, Nuno Lopes <[EMAIL PROTECTED]> wrote: > It can also have some use if we > decide to investigate the usage of an off-the-shelf (conservative) > garbage collector such as Boehm's (maybe in next year's SoC). >
As an aside, I was also thinking about this throughout the course of the project. It's said that reference counting is the slowest form of garbage collection since the reference counts must constantly be maintained. Changing to a tracing garbage collector won't require these macros, because reference counts would be eliminated altogether. However, it would be sort of a big pain to implement Off the shelf garbage collectors such as BDW would be inappropriate because we use some weird kinds of "pointers" (such as object handles) stored in weird kinds of ways (such as a zend_hash object). I think it would be pretty inefficient, since those implementations just scan the stack, registers and heap and we're trying to do GC not for the PHP interpreter, but for the code the PHP interpreter is running. I have a certain suspicion that a traditional mark-and-sweep collector might be faster if just on the virtue of eliminating the refcount field and getting rid of tons of cache misses that way. For just displaying page, there wouldn't be much memory used and that's all freed at the end of a request anyway: all of that reference counting overhead would just disappear. For larger scripts that use a lot of memory, the only problem would be pause times but in most real life cases, it seems the total time would be shorter than reference counting. However, I'm not sure if that would be the case in PHP: rummaging through objects scattered all over memory would result in a lot of cache misses. The question is whether that is greater than all the misses we're currently having just managing the refcount. However, answering that question would require implementing the thing, and that honestly seems like it would be a bit of a nightmare. Roots would include zvals linked to PHP variables, the stack of the running PHP code, and the stack and heap of the PHP interpreter itself. It would've been far easier if PHP had been designed from the ground up to use some sane way of managing memory, but with the current situation, with extensions depending on reference counting, it's pretty difficult. If ever a version of this patch is committed, you'll be able to see that the cycle collector touches the whole reference counting mess extremely minimally, which is why it was relatively safe to implement. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
