Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54409
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E3BF930.9030701@toolpark.com>
References: <CACs9DU4jhCBHEYXd-N1rvYE5jbCDztvXEi=gsZh4ozLoqQrRXw@mail.gmail.com>
	<CACs9DU6MAmJt6veeOEVdkL5spO+8YVgmvbhioc7ORWZH-1d1LQ@mail.gmail.com>
	<4E3898B0.40809@sugarcrm.com>
	<CACs9DU4Z2ZR+VkbZoQry=N6WJqR1ZemkODiG7QeUvKNS_d_UHQ@mail.gmail.com>
	<4E38EC0C.9080304@lerdorf.com>
	<4E38FA2E.4030605@lsces.co.uk>
	<4E38FC67.9090200@toolpark.com>
	<CACs9DU5EsXi1jUDnswOCFiEOMgitOPDQE-X_Pp_G_9L4=dsdkQ@mail.gmail.com>
	<CAEZPtU79jxjT52=1HYRfaDE0z6cb5pDGD9h4czspiHaOC_-Kyg@mail.gmail.com>
	<CACs9DU6_oDZAKEDvOxybSvXR5moDCP2ZM=WhLEe+Ui=EkpuToQ@mail.gmail.com>
	<CACQesk5_bRDXCpuhB-bDb1LF4ks7s1pzSPo90EuSb-NtbPGxRQ@mail.gmail.com>
	<CAM4sM9Hb3Qyig8xssrJd3YWq9L60xQkXHG9sY9=XOD37wFXLog@mail.gmail.com>
	<4E39E89F.8060605@sugarcrm.com>
	<4E3A3643.2070305@toolpark.com>
	<4E3A4793.2070209@sugarcrm.com>
	<4E3A91E8.1020107@toolpark.com>
	<4E3ACA42.8000001@sugarcrm.com>
	<CAH-PCH4+KTZYd6cNC-MaC8wu2sxK1BXC967c1yiA-ohXFPgOiQ@mail.gmail.com>
	<CAGsnKxb_F-xG-grZUaCv8D=Yrs0=0YE9a8H+Z7_TNXOnjq3+=A@mail.gmail.com>
	<4E3BF930.9030701@toolpark.com>
Date: Fri, 5 Aug 2011 18:29:44 +0200
Message-ID: <CACs9DU6S3NcppNYoTgtMwuyCO7ygGu6jOm665b9UMQtnqB2zQw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0015176f1aaef26c4604a9c49a60
Subject: Re: [PHP-DEV] [VOTE] Weak References
From: landeholm@gmail.com (Hannes Landeholm)

--0015176f1aaef26c4604a9c49a60
Content-Type: text/plain; charset=ISO-8859-1

Soft references could theoretically be implemented if PHP only implemented
weak references even though the implementation would consist of a very ugly
and "coincidental" hack.

Lets say you had an object A that you wouldn't want to be collected until
approximately when PHP needs more memory. E.g. we want to implement some
sort of caching behavior. Note the difference towards weak references which
allows objects to be collected directly when they are not strongly
referenced anymore. In the caching scenario we don't know weather the object
might be used again so we want it to be retained in memory as long as it's
not a problem - e.g. as long as PHP doesn't use "too much" memory.

Now after object A is created we create a weak reference for it in our
cache. Then we create another object B which is just a StdClass with a
single field "ptr" which is a strong reference to A. Then we create a strong
reference from A to B and so a cyclic reference memory structure is born. A
(and B) will now be unable to be garbage collected until gc_collect_cycles
runs which happens when the "root buffer is full" - piggybacking on PHP's
internal approximation of when enough memory has been allocated that the
probability is high enough for garbage cycle collection to be worth it.

This also assumes that you can add an arbitrary property to the A object
without disrupting it's behavior. Adding arbitrary properties to other
objects violates encapsulation and is generally not good design. Also since
this implementation of a soft reference depends on internal PHP
implementation I would avoid such design though unless careful testing is
made and the behavior is disabled if an incremented PHP version is detected
where there is a possibility that the PHP GC implementation might have
changed.

It's interesting to think about though.

Also I would not rely on "ticks" for anything really except debugging. It's
an unreliable performance killer.

~Hannes

--0015176f1aaef26c4604a9c49a60--