in reply to Re^2: Does using globals via our() in mod_perl scripts lead to apache child size growth?
in thread Does using globals via our() in mod_perl scripts lead to apache child size growth?

Memory that is actually freed (which you can do by setting a variable to undef) gets returned to Perl for other uses and in some cases on some systems gets returned to the OS. If you don't explicitly undef, it stay allocated to the variable that used it.
  • Comment on Re: Re^2: Does using globals via our() in mod_perl scripts lead to apache child size growth?

Replies are listed 'Best First'.
Re^4: Does using globals via our() in mod_perl scripts lead to apache child size growth?
by Aristotle (Chancellor) on Nov 22, 2003 at 21:42 UTC
    Does just letting it go out of scope count the same as explicit undef?

    Makeshifts last the longest.

[reply]
      No, you have to set it to undef.
[reply]
        I have to disagree.

        From http://perl.apache.org/docs/1.0/guide/performance.html#toc_Memory_leakage
        --
        Memory leakage

        Scripts under mod_perl can very easily leak memory! Global variables stay around indefinitely, lexically scoped variables (declared with my()) are destroyed when they go out of scope, provided there are no references to them from outside that scope.

        Perl doesn't return the memory it acquired from the kernel. It does reuse it though!
        --

        The last line does imply that you shouldn't do things like slurp a 100MB file into a my() var, because even though it will be freed, that 100MB is only available to Perl and won't go back to the OS. However, it's not as bad as if my() vars were never freed automatically. If that were the case, nearly every mod_perl application out there would eventually use up all available memory (without Apache::SizeLimit coming to the rescue).
[reply]

In Section Seekers of Perl Wisdom