Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32050
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Tue, 4 Sep 2007 21:00:47 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <849426349.20070904210047@marcus-boerger.de>
To: "David Wang" <planetbeing@gmail.com>
CC: "Nuno Lopes" <nlopess@php.net>, internals@lists.php.net, andi@php.net, 
	<dmitry@php.net>
In-Reply-To: <ee59b7580709040938t6bde9dd4na121b9a7b5cb3599@mail.gmail.com>
References: <ee59b7580709040724y23427c4bq2f6cd3b2ee409276@mail.gmail.com> <20070904162613.4qgfdddo7scw8o8w@w13.mail.sapo.pt> <ee59b7580709040938t6bde9dd4na121b9a7b5cb3599@mail.gmail.com>
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,

Tuesday, September 4, 2007, 6:38:17 PM, you wrote:

> On 9/4/07, Nuno Lopes <nlopess@php.net> 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