Hello David, Tuesday, September 4, 2007, 6:38:17 PM, you wrote:
> 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 What is the problem with those objects? Basically there are at least three seperated memory areas involved. First the zend_object container, the real object and one or several zvals. The gc would simply have to decrease refcount on zend_objects if their zval gets down to zero and then leave zend_object gc'ing to the object storage. > 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. Question for development, how do we ensure that starting from a specific point in time we enforce usage of those macros? The one thing that comes into my mind is that we could have the members [is_ref,refcount] prefixed with something different when running in debug mode, or insert some random prefix there....(?) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
