Re: Query on refcounting with container objects

Yes and no. Perl doesn't release the memory back to the OS. However, the memory isn't accessible, which means it's available for reallocation before Perl asks the OS for more memory.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re: Query on refcounting with container objects

Replies are listed 'Best First'.
Re^2: Query on refcounting with container objects by Joost (Canon) on Jul 29, 2004 at 19:48 UTC
But it will (should, if it doesn't, it's a bug) destroy the array and all elements in it and reuse their memory in perl except for the one element that still has a refcount > 0. So, a standard perl container (hash or array) will have a reference to its elements, but not the other way around. This is also true for regular references; they only point 1 way and only up the refcount for the variable that they point to. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^2: Query on refcounting with container objects by gmpassos (Priest) on Jul 30, 2004 at 05:02 UTC
One thing is to say that the process of the Perl interpreter got an amount of memory from the OS, and other thing is to say that Perl internally uses this memory with a SV, where a SV in Perl can be a data type (SCALAR, ARRAY, HASH, CODE, etc...). So, when a reference to a SV goes out, yes, this will be undefined/destroied, and the memory (inside the process) used to represent this SV will be used in the future for new SVs. Now about keep some back reference of who hold a SV, like in an ARRAY or HASH, I say that not! The SV doesn't know if it exists inside another ARRAY or HASH value, it's just a SV. Graciliano M. P. "Creativity is the expression of the liberty".	[reply]