When does perl free its lexical variable from memory?

I read about a lexical variable from one site, explaining, A variable declared using the keyword "my" is a lexical variable. It lives from where it was declared using the my keyword until the end of the current block. This is the area of ​​the lexical variable.

My doubt is that if the scope is over, is the lexical variable free from memory or not? If a lexical variable is not freed from memory after it has finished the scope, when is it freed from memory? Can someone explain me clearly?

+6
source share
4 answers

Perl lexical variables like to hold on to their memory, so you can simply reuse it the next time the vocabulary is in scope. Usually for numbers, links, small lines or hashes or arrays with multiple elements, this does not matter.

For lexical files containing large strings or arrays or hashes with a large number of elements, you can explicitly use undef yourvarname to free their memory. (Although this simply frees the memory that the Perl process will use for other things, rather than freeing it from other processes.)

+6
source
Strictly speaking, you really do not know. The official documentation is somewhat cautious when discussing memory usage. If and when memory is freed, it depends on the internal elements of perl. Any answers to your question are based on knowledge (or assumptions) about the internal components that are subject to change. However, there are a couple of things we can know:
  • The memory used by perl will be fixed by the operating system when the execution is completed.
  • The memory allocated for a variable cannot be freed if there is any reference to it.

There are no guarantees beyond this, although perlguts provides some insight into the behavior of internal elements:

Perl uses a link-based garbage collection mechanism. SVs, AVs or HV (xV for brevity in the following) begin their life with reference counter 1. If the countdown of the xV reference ever drops to 0, then it will be destroyed and its memory will become available for reuse.

This usually does not happen at the Perl level, unless the undef'ed variable or the last variable containing a reference to it is changed or overwritten.

The memory “reusable” is not quite the same as the release. This allows perl to use memory for something else, but does not return it to the operating system. You should not expect perl to return memory to the OS before exiting.

From a developer's point of view, my memory management tip is:

  • Do not load more data into memory immediately than necessary. (e.g. read files one at a time, rather than tearing apart if possible)
  • Declare limit variables in the smallest reasonable area.
  • Do not keep links to data when it is no longer needed. (Or let it go out of scope or explicitly clear the link.)
  • Define large variables when they are no longer needed. (e.g. via undef %hash )

Performing these steps will not necessarily free / reuse the memory, but it maximizes the chances that it will be.

+4
source

There is some confusion here. Perl has memory for the variable in the symbol table and memory for the data stored in the variable. But in all cases, Perl pools free up memory so that it can later be reused.

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

The memory for data is not merged until the reference count reaches zero. This is useful when you want to return data to the calling routine. If memory was freed when the subroutine returns, data will be lost.

Rule of thumb: If you do not create a circular link, Perl will take care of garbage collection for you.

The second rule of thumb: do not create circular references.

+2
source

The lexical variable will be “freed” when it goes out of scope. If this indicates a data structure with circular references, this structure will not be “released”, even if no one points to it.

0
source

Source: https://habr.com/ru/post/1012717/


All Articles