Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:32174 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78893 invoked by uid 1010); 10 Sep 2007 11:49:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 78878 invoked from network); 10 Sep 2007 11:49:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Sep 2007 11:49:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Linux 2.6 Received: from [85.214.94.56] ([85.214.94.56:51442] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8D/09-19032-53F25E64 for ; Mon, 10 Sep 2007 07:49:11 -0400 Received: from dhcp-172-28-204-149.zrh.corp.google.com (unknown [193.142.125.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id D20151B3622; Mon, 10 Sep 2007 13:49:06 +0200 (CEST) Date: Mon, 10 Sep 2007 13:49:12 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <12710107579.20070910134912@marcus-boerger.de> To: David Wang CC: Marcus Boerger , Nuno Lopes , , , In-Reply-To: References: <20070904162613.4qgfdddo7scw8o8w@w13.mail.sapo.pt> <849426349.20070904210047@marcus-boerger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and is_ref From: helly@php.net (Marcus Boerger) Hello David, Wednesday, September 5, 2007, 4:19:05 AM, you wrote: > On 9/5/07, Marcus Boerger 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