Hello David, Wednesday, September 5, 2007, 4:19:05 AM, you wrote:
> On 9/5/07, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> 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. > Hmm, maybe we have a misunderstanding here because I don't quite > understand what you mean. :) In that paragraph, I was saying how > implementing a traditional tracing garbage collector would mean > refcounts are no longer necessary. These macros track refcounts, so > they would also be no longer necessary. All true, yet at soume point your gc will free a zval - and a zval only - unless you also use the gc'ing for every object storage in use. Either way zvals and their objects are seperate things and multiple *different* zvals can point to the same object in an object storage. >> 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....(?) > In my own code, I have a "__gc" on refcount and is_ref so I get thrown > an error if there's a place I failed to macroize. I removed that for > this patch, but that's a very good point. If there are no objections, > that or another prefix or suffix can be put back into the patch. > David Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
