Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32048
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:54:56 -0700
Message-ID: <698DE66518E7CA45812BD18E807866CEA2A0EC@us-ex1.zend.net>
Thread-Topic: Re: [PHP-DEV] Patch for macros for tracking refcount andis_ref
Thread-Index: AcfvInQHAAp9pzQBSuWUU/cJLhTqZgAAij7A
References: <ee59b7580709040724y23427c4bq2f6cd3b2ee409276@mail.gmail.com><20070904162613.4qgfdddo7scw8o8w@w13.mail.sapo.pt><ee59b7580709040938t6bde9dd4na121b9a7b5cb3599@mail.gmail.com> <20070904193517.i279eprj40ogkc0k@w13.mail.sapo.pt>
To: "Nuno Lopes" <nlopess@php.net>,
	"David Wang" <planetbeing@gmail.com>
Cc: <internals@lists.php.net>,
	<andi@php.net>,
	<dmitry@php.net>
Subject: RE: Re: [PHP-DEV] Patch for macros for tracking refcount andis_ref
From: andi@zend.com ("Andi Gutmans")

See below:

> -----Original Message-----
> From: Nuno Lopes [mailto:nlopess@php.net]
> Sent: Tuesday, September 04, 2007 11:35 AM
> To: David Wang
> Cc: internals@lists.php.net; andi@php.net; dmitry@php.net
> Subject: Re: Re: [PHP-DEV] Patch for macros for tracking refcount
> andis_ref
>=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
> surely it wouldn't be the top performance GC, but I think it worths a
> try. And it doesn't seem difficult to use that GC (after your patch
> specially).

Figuring out the roots is *very* hard with PHP because of all the
extensions managing their own zvals. I don't think it's feasible nor
will it be very beneficial.

> > 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
> exactly. for most PHP requests the GC wouldn't even run. The garbage
> would be collected after the request, thus reducing the latency of the
> request (for Gopal pleasure :)

Probably not. Executing PHP scripts is very heap intensive and if you
didn't run the GC during execution you would be eating up *lots* of
memory even for relatively short requests. This would have a significant
impact on the # of Apache processes you can run on a given box. So I
think it actually wouldn't work well for us.
=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
> implementing a GC from scratch is a difficult job, yes and hence my
> idea to try an existenting GC. But if we look to the GCs used by e.g.
> the Common Lisp implementations, we see that they have highly-tuned
> and highly-performant GC implementations that take advantage of how
> the internal structures are implemented. And I suspect Java does that,
> too.
>=20
> Well, maybe we can find some crazy student next year to do it *hint*
> :). Or maybe I get crazy too one of these days ;) (well I still have
> to pick something to do for the master thesis..)

Not that I think these kind of GCs are always a bad idea but they don't
come without their own baggage and set of problems.

Andi