I have mixed feelings about this proposal - from one point it's quite neat - ability to mark circular references for the memory manager so it can free them sounds very delicious, especially for some cases. I had run into my own bunch of problems with memory in PHP in the past and right now I'm running a daemon written in PHP in production on 5.3.6. Careful construction and knowledge that circular references actually do harm I did add safeguards that actually clean up the objects in recursive manner (and objects have internal flags that cleanup has been initiated - that way I make sure I cleanup the same object only once). That sort of planing at the design stage makes it far more friendly with memory, so it doesn't mean that PHP should have soft references.
My opinion is that if this can be done without using significant resources and will not have major issues while implementing - it can be added, otherwise just skip it - better off fixing bugs and optimizing :) 2011/8/6 Lars Schultz <lars.schu...@toolpark.com>: > Am 06.08.2011 02:14, schrieb Hannes Landeholm: >> >> Yeah I think there's a lot of misunderstandings going on with weak/soft >> references and how the garbage collector works. Weak/soft references is >> not >> some kind of solution to the cyclic reference problem. The GC takes care >> of >> that already. You can use whatever OOP patterns with whatever reference >> graphs you like Lars, the GC will free the entire structure as soon as the >> cyclic collector runs after you are not referencing it anymore. You might >> have become a bit confused with my last post where I explained how one >> could >> theoretically hack together a soft reference implementation by using weak >> references and some properties of cyclic collection. Also property access >> performance is off-topic. > > I did not misunderstand how weak/soft-references or php's new GC works. > > Having a GC collect circular references is neat, but if I remember > correctly, collecting them (which is why there are other, faster methods but > which require more memory) is neither simple nor fast (whatever that means) > so...if I can assist the GC by clearly stating that my child-objects may be > collected as soon as they and their parent are not referenced from userland > anymore thus not requiring the GC and thus freeing memory as soon as > possible,...seems like an optimization worth thinking of. Especially if I > tend to have vast structures with hundreds of objects. > > In 5.2 (we can't move our project to 5.3 yet because of a BC issue) i had to > manually clear those cycles before dropping the last userland reference to > the tree of objects because otherwise I'd run into memory problems when > processing alot of those trees. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
