Page 2 of 2

Posted: Sun Mar 26, 2006 4:19 pm
by alex.barylski
d11wtq wrote:I agree with Hockey here. From what I've read, including in the Zend documentation for writing extensions, the ZE has some advanced memory management features. Then again, what feyd mentioned about memory leaks in <place-name-of-some-big-library-here> rings a bell.
I am not sure thats possible...

Extension writers are told to use Zend memory managment functions, which appear to be wrappers around crt functions, but with additional facilities, like GC.

If this is the case, a resource leak in an extension is likely caused by a developer using CRT functions instead of the Zend API, in which case no amount of unset() will release that memory.

Perhaps if the developer used Zend API memory managment functions, but didn't explicitly call efree() on memory, unset() might have knowledge of the memory, but GC would likely take care of that anyways.

Zend web site: "While an extension may, in theory, rely on ZE to free non-persistent memory automatically at the end of each page request, this is not recommended".

Basically what that tells me, is that ZE can take care of resources that extension developers don't free, but it's not as "clean" as explicitly freeing resources.

Now my question becomes, how does Zend handle memory clean up...using GC and reference counting...

when a reference count reaches zero, is efree() called or is it flagged as garbage and taken care of GC at script termination?

If this is the case, then calling unset() in PHP to correct an extension leak is pointless, cuz either way it happens at shutdown. If unset() does free memory immediately, then there might be some benefit to it.

http://ca3.php.net/manual/en/function.unset.php#56332

Not sure exactly what the guy in the post is saying, but it sounds like unset() frees the memory in the sense that it's no longer used by PHP, but it is still technically allocated and Zend just writes over top of it when new memory is needed.

This makes sense on one hand and on another no so much...

Cheers :)

Posted: Sun Mar 26, 2006 4:23 pm
by s.dot
Indeed, I am confused actually. I guess i'll stick to feyd's suggestion that 'helping php free memory cant hurt' and continue using unset()

Plus, if its not giving me errors, then I guess it really cant be wrong.

Posted: Sun Mar 26, 2006 4:28 pm
by alex.barylski
d11wtq wrote:
scottayy wrote:
scottayy wrote:Due to the reference-counting system introduced with PHP 4's Zend Engine, it is automatically detected when a resource is no longer referred to (just like Java). When this is the case, all resources that were in use for this resource are made free by the garbage collector.
If this is the case, why doesn't unset() throw out an error like it does if you unset($invalid_variable)
I think that basically mean there will still be a pointer to the data if it could still be accessed.

For example, when you're inside a function every variable you create will be available only in the local scope of the function, therefore, when the function ends, the memory used to hold those variables will be freed automatically. If you have a global variable defined in your script I don't think ZE will delete it from memory until the script ends.

In other languages (C/C++...) if you create a pointer to something in memory and then you leave the scope of that pointer without freeing the memory up with "delete" you've just lost X Blocks of memory that you can never recover. PHP avoids that with ZE.

Hmm... I guess the use of unset() could be valuable in large scripts where global data is only needed for a short section of the script.
I'm getting mixed messages about unset() and this issue...

Does it actually de-allocate memory or just flag it as free internally to Zend and get over written?

If it's not physically de-allocated, then unset does nothing until script shutdown.

In the PHP thread I submitted earlier one guy says something about massive amounts of data used in a function and calling unset() on data before returning reduced his memory load - suggesting de-allocation via efree().

How credible that statement is though, I dunno. :?

Others say, memory isn't physically de-allocated, but just over written...

I would look into the source myself, but I can't unzip the damn gzip/tar files or whatever they are :(

Cheers :)

Posted: Sun Mar 26, 2006 4:32 pm
by feyd
Even if it's marked as free, that's now memory that could be used for something large that needs memory. So even if it doesn't actually free the memory in C terms, it still free's it in php's terms.