Re: avoiding child death by size limit

Perrin Harkins <[email protected]>
Newsgroups gmane.comp.apache.mod-perl
Message-ID <[email protected]>
On Fri, Dec 11, 2009 at 5:56 PM, André Warnier <[email protected]> wrote:
> When you say "It (perl) will keep the memory", do you mean that
> - the perl interpreter embedded in this Apache child will keep the memory
> (and not return it to the OS), but will re-use it if possible for other
> variable allocations happening within its lifetime ?
> or
> - the perl interpreter embedded in this Apache child will keep the memory
> (and not return it to the OS), and never re-use it again for any other
> variable allocation happening within its lifetime
> (in other words, this is a leak) ?

Option 3:
Perl will keep the memory and reuse it for that exact same lexical
variable the next time you enter that section of code.  It's a
performance optimization that is usually a good thing, unless you put
a lot of data in one lexical in some code that you rarely run.

It's not a leak.  Perl tracks the memory and will reuse it, just not
for any other variables.

> Does any guru care to provide some simple real-world examples of when memory
> once allocated to a variable is/is not being re-used, in a mod_perl handler
> context ?

It's simple to see.  Slurp a file into a lexical.  Let it go out of
scope.  There are many posts on this subject in the archives here as
well as on PerlMonks and the p5p archives.

> Maybe on this last subject, what I gather from this and other discussions
> I've seen, is that once the Perl interpreter obtained some memory from the
> OS, it rarely returns it (before it exits); and if it does, it is in any
> case not practically predictable in a cross-platform way, so one cannot rely
> on it.  Is that a fair interpretation ?

Yes, you can't expect to get memory back.

- Perrin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.