Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26890
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <52.F2.00543.E5A8C754@pb1.pair.com>
To: internals@lists.php.net
Date: Mon, 11 Dec 2006 00:28:52 +0200
User-Agent: Thunderbird 2.0a1 (Windows/20060724)
MIME-Version: 1.0
References: <4574C97F.8020507@adaniels.nl>    <22319.204.16.229.245.1165342794.squirrel@www.l-i-e.com>    <4575F689.3000709@adaniels.nl> <61711.209.254.223.2.1165695322.squirrel@www.l-i-e.com>
In-Reply-To: <61711.209.254.223.2.1165695322.squirrel@www.l-i-e.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] destruction of cross-referenced objects
From: ants.aasma@gmail.com (Ants Aasma)

Richard Lynch wrote:
> I could be full of it, as I don't do PHP OOP that much, but it seems
> to me that if your __dtor (or whatever it is in PHP) walks through the
> members and unset()s them to not point to the parent/child any more,
> in a structured way so that you don't chop off your own foot, then you
> will not create these giant cyclic un-salvagable data structures.
> 
> If you don't do that, then, yes, PHP will most likely not be able to
> track your data storage for you.
>
 > ... snip ...
> 
> I truly believe that if you are putting that much faith/reliance in
> PHP's GC and refcount values, then you've probably got a data
> structure that needs some more effort in maintenance and needs to
> clean up after itself, rather than rely on the semi-random timing of
> PHP's GC.
> 
> So it's not that you couldn't improve PHP to do it for you -- It's
> that you'd be attacking the symptom rather than the disease. :-)

PHP's GC is not random nor semi-random. It's completely deterministic: 
when the last reference to a value is deleted, then the value itself is 
freed and if appropriate the destructor is called. If your 
datastructures are strictly hierarchical then yes, you can use 
finalizing methods that free the cyclic references. Unfortunately 
sometimes that is not the case. Sometimes you want to have references to 
objects from several places, which pretty much means that to avoid leaks 
you have to implement your own ref-counting. Only way to avoid that is 
to use the "random" variety of garbage counting that flags all values 
reachable via active scopes and deletes the rest.

Another thing that's missing from PHP is weak references. If you want to 
have an identity map that doesn't keep everything ever used in memory, 
then you need to have references to objects that don't stop the GC from 
freeing the object. An identity map is a construct that ensures that you 
have at most one instance of every logical entity. I had to implement an 
identity map that releases unused objects in a JavaScript application 
recently. Because JavaScript doesn't have weak references I had to 
implement my own ref counting and I must say that that was probably the 
most complex and bug prone thing in the whole 30kLOC application.

When you don't care about mem leaks, then you don't need "true" garbage 
collecting and weak references. This is the case when you use the PHP 
standard request-response model /  everything gets freed when the 
request ends. But if you need to do batch processing involving complex 
datastructures and haven't thought memory management completely through, 
then you're pretty much *screwed* without them.

This is precisely the reason why for serious stuff we at my employer 
prefer Python to PHP. We need to use our business logic in batch 
processing and manual memory management is just too complex, bug prone 
and time consuming. PHP doesn't have either weak refs nor true gc, the 
general consensus among core developers seems to be that it's not needed 
and we don't have enough resources to develop it ourselves. It's easier 
to rewrite the useful PHP libraries in Python (and get a more 
aesthetically pleasing language, ignoring the god awful semantically 
significant whitespace).

--
Ants Aasma