Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32045
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.55.154.23 as permitted sender)
Message-ID: <20070904193517.i279eprj40ogkc0k@w13.mail.sapo.pt>
Date: Tue, 04 Sep 2007 19:35:17 +0100
To: David Wang <planetbeing@gmail.com>
Cc: internals@lists.php.net, andi@php.net, dmitry@php.net
References: <ee59b7580709040724y23427c4bq2f6cd3b2ee409276@mail.gmail.com>
	<20070904162613.4qgfdddo7scw8o8w@w13.mail.sapo.pt>
	<ee59b7580709040938t6bde9dd4na121b9a7b5cb3599@mail.gmail.com>
In-Reply-To:  <ee59b7580709040938t6bde9dd4na121b9a7b5cb3599@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-15;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs)
Subject: Re:  Re: [PHP-DEV] Patch for macros for tracking refcount and
	is_ref
From: nlopess@php.net (Nuno Lopes)

> 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.

surely it wouldn't be the top performance GC, but I think it worths a =20
try. And it doesn't seem difficult to use that GC (after your patch =20
specially).


> 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.

exactly. for most PHP requests the GC wouldn't even run. The garbage =20
would be collected after the request, thus reducing the latency of the =20
request (for Gopal pleasure :)


> 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.

implementing a GC from scratch is a difficult job, yes and hence my =20
idea to try an existenting GC. But if we look to the GCs used by e.g. =20
the Common Lisp implementations, we see that they have highly-tuned =20
and highly-performant GC implementations that take advantage of how =20
the internal structures are implemented. And I suspect Java does that, =20
too.

Well, maybe we can find some crazy student next year to do it *hint* =20
:). Or maybe I get crazy too one of these days ;) (well I still have =20
to pick something to do for the master thesis..)

Nuno