Perl is famous for not giving memory back
Well... it depends what you mean by that. If you have removed all references to the memory then it will be released to the Perl intepreter for reuse.1 However, I don't think that Perl interpreter gives it back to the OS for use by other processes.
Remember that there are two levels of memory pools: the OS and Perl. So when your program needs some memory Perl will check its internal pools and see if it has any it can allocate. If there is no memory (of the right size, etc.) kicking around then it will ask the OS for more. When there are no more references to a piece of memory left then Perl will notice the reference count has hit 0 and add it to Perl's internal free list. It will not give it back to the OS for use by other programs.
Note that this behavior is common to most programs since malloc and free manipulate the internal pools of a program and ask the OS for more but do not release it back until the program ends. On UNIX the brk and sbrk call are the system calls that actually manipulate the memory that a program can see. However, these only allow you to shrink or grow the heap at the end. So if you have 1 large array then allocate another small integer after it on the heap even if the large array is freed your program could not shrink the heap until the integer goes away (or if the program compacts itself).
I don't think Perl compacts the heap since it probably assumes that if you allocated memory once you are likely to need it again. Most of the time this is a reasonable assumption and pays off for performance.
-ben
1 - Although things are sometimes not freed when you think they should be. Some loop variables are kept around if Perl thinks the loop is likely to happen again.
In reply to Memory, Perl and the OS
by knobunc
in thread A question of memory, mod_perl, and references and subroutines
by Yohimbe
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |