NYCPHP Meetup

[Jesse Callaway]

On Tue, Feb 3, 2009 at 6:35 PM, Michael B Allen <ioplex at gmail.com> wrote:
> On Tue, Feb 3, 2009 at 5:26 PM, Daniel Convissor
> <danielc at analysisandsolutions.com> wrote:
>> Hey Again Mike:
>>
>> On Tue, Feb 03, 2009 at 05:21:52PM -0500, Daniel Convissor wrote:
>>>
>>> On Tue, Feb 03, 2009 at 03:29:09PM -0500, Michael B Allen wrote:
>>> >
>>> >  3. PHP does not have garbage collection
>>>
>>> Yes it does.  That's what the various gc_* php.ini settings are for:
>>> http://php.net/session.configuration
>>
>> Doh!  Those are for session garbage collection.  None the less, PHP does
>> have garbage collection.
>
> Not really. But it wouldn't be hard to split some hairs in this conversation.
>
> My understanding is that true "garbage collection" doesn't immediately
> free objects when they fall out of scope or when they're set to nil
> but rather maintains table references that can be used to periodically
> figure out how to efficiently free things later. Usually there's a
> background process that does this in a way that allows programs to
> "run wild" but then free things when the CPU becomes idle or if free
> memory runs low.
>
> I'm not an expert on this stuff so my description is probably
> oversimplified but PHP does not do the above. It just frees everything
> as soon as it's unset. Or maybe it waits to some degree but I don't
> think there's a sophisticated algorithm behind it, it doesn't maintain
> a separate table of allocations (the zvals and resources *are* the
> allocation table) and it doesn't use a separate process to do any of
> this. GC has never been a really high priority since PHP scripts are
> usually fairly short lived.
>
> An important implication of this is that I would imagine if you tried
> to write a long-lived PHP script that did a lot of work like a CLI
> script run from cron, you'd find the script would behave poorly after
> a while and may even just run out of memory entirely if you didn't
> aggressively unset() things. With proper GC that would not happen.
>
> I have written PHP extensions and to do that you need to know how
> things are allocated internally. There are two types of memory objects
> - zvals and resources. The zvals are used to represent arrays,
> objects, variable length data (strings), integers and doubles. Since
> you can completely traverse a zval and all descendants, PHP can
> automatically delete the entire tree when the root zval is unset().
> Resources are managed by extensions and have deconstructors that are
> responsible for freeing all memory associated with them. These are
> used for things like file handles, database connections, drawing
> contexts and so on. If you unset a resource it fires the deconstructor
> which must explicitily go through and free any memory that has been
> allocated by the resource.
>
> My instinct is that PHP probably does delay deallocation of things
> that are unset for a short time reasoning that the script will
> probably complete by the time it needs to actually free things. But
> that's pure speculation on my part. It just seems like a smart thing
> to do. Then again, if you unset() something and then look at
> memory_get_usage it shows the memory has been deallocated (although it
> could just be lying or call the "collection" routine first).
>
> Again, I'm not an expert on this so I've probably trampled some truth
> in a message this size. But I know for sure that it is not accurate to
> say that "PHP uses garbage collection".
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show_participation.php
>

Um did the baby get thrown out with the bathwater? I think a lot of
people want to see this module go mainstream.

-jesse