When does perl free its lexical variable from memory?

Question

I read about lexical variable from one website, in that they explain, A variable declared using the "my" keyword is a lexical variable. It lives from the place where it was declared using the my keyword till the end of the current block. This is the scope of the lexical variable.

My doubt is, if the scope is finished, the lexical variable is free from the memory or not? If the lexical variable is not free from the memory after finished the scope mean, when it will free from the memory? Can anyone explain to me clearly?

Answer 1

Perl lexical variables like to hold on to their memory so it can just be reused the next time the lexical is in scope. Normally, for numbers, references, small strings, or hashes or arrays with few elements, this is not significant.

For lexicals that hold large strings or arrays or hashes with a large number of elements, you can explicitly use undef yourvarname to free their memory. (Though this just frees the memory to be used for other things by the Perl process, not frees it to other processes.)

Answer 2

Strictly speaking, you don't really know. The official documentation is somewhat circumspect when discussing memory usage. If and when memory is freed is up to the perl internals. Any answers to your question are based on knowledge of (or speculation about) the internals, which are subject to change. That said, there are a couple of things we can know:

• Memory used by perl will be reclaimed by the operating system when execution ends.
• Memory allocated to a variable can't be freed if there are any references to it.

Beyond that there are no guarantees, though perlguts provides some insight into the behavior of the internals:

Perl uses a reference count-driven garbage collection mechanism. SVs, AVs, or HVs (xV for short in the following) start their life with a reference count of 1. If the reference count of an xV ever drops to 0, then it will be destroyed and its memory made available for reuse.

This normally doesn't happen at the Perl level unless a variable is undef'ed or the last variable holding a reference to it is changed or overwritten.

Memory being "made available for reuse" isn't quite the same as being freed. It allows perl to use the memory for something else but does not return it to the operating system. You shouldn't expect perl to return memory to the OS prior to exiting.

From a developer's perspective, my advice on managing memory usage is:

• Don't load more data into memory at once than is needed. (e.g. read files line-by-line instead of slurping if possible)
• Limit variable declarations to the smallest reasonable scope.
• Don't keep references to data when it is no longer needed. (Either let it go out of scope or explicitly clear the reference.)
• Undefine large variables when they are no longer needed. (e.g. via undef %hash)

Doing these things won't necessarily result in memory being freed/re-used, but it maximizes the chances that it will be.

Answer 3

There is some confusion here. In Perl, there is memory for the variable in the symbol table and memory for the data stored in the variable. But in all cases, Perl pools "freed" memory so it can reuse it later.

The memory for the variable is not pooled until the subroutine returns. This is in case of loops, where the same memory will be reused for the variable.

The memory for the data is not pooled until its reference count goes to zero. This is useful when you want to return the data to the calling subroutine. If the memory was freed when the subroutine returned, the data would be lost.

The rule of thumb is: Unless you create a circular reference, Perl will take care of garbage collection for you.

The second rule of thumb: Don't create circular references.