Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32047
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 4 Sep 2007 11:50:15 -0700
Message-ID: <698DE66518E7CA45812BD18E807866CEA2A0E2@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] Patch for macros for tracking refcount and is_ref
Thread-Index: AcfvEhjD2/7F0tW5R2GiIIs5bp4siQAEk1/Q
References: <ee59b7580709040724y23427c4bq2f6cd3b2ee409276@mail.gmail.com> <20070904162613.4qgfdddo7scw8o8w@w13.mail.sapo.pt> <ee59b7580709040938t6bde9dd4na121b9a7b5cb3599@mail.gmail.com>
To: "David Wang" <planetbeing@gmail.com>,
	"Nuno Lopes" <nlopess@php.net>
Cc: <internals@lists.php.net>,
	<andi@php.net>,
	<dmitry@php.net>
Subject: RE: [PHP-DEV] Patch for macros for tracking refcount and is_ref
From: andi@zend.com ("Andi Gutmans")

Btw, when can you make a PHP 5.2.x version of the patch available so
that we can start playing around with it and test it?

> -----Original Message-----
> From: David Wang [mailto:planetbeing@gmail.com]
> Sent: Tuesday, September 04, 2007 9:38 AM
> To: Nuno Lopes
> Cc: internals@lists.php.net; andi@php.net; dmitry@php.net
> Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and
> is_ref
>=20
> 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).
> >
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.