in reply to Understanding garbage collection specifics...

Have you read the FAQ entry on this? Memory used and free-d by Perl is not released to the O/S (except in MacOS, if I recall correctly), so the apparent memory usage will not go down, but that memory is still available for Perl to re-use for other items.
-- Randal L. Schwartz, Perl hacker
  • Comment on Re: Understanding garbage collection specifics...

Replies are listed 'Best First'.
Re^2: Understanding garbage collection specifics...
by merlyn (Sage) on Feb 01, 2007 at 12:17 UTC
    I didn't write that recently. Had I written it recently, I would have said that any malloc that is smart enough to use mmap() instead of just sbrk() can return chunks back to the O/S. And apparently, that includes many current popular Unix-like operating systems.
Re^2: Understanding garbage collection specifics...
by cLive ;-) (Prior) on Feb 01, 2007 at 09:24 UTC
    I knew that, but I was wondering why undef does free the memory and why Perl doesn't just do that automatically.
      As an optimisation, perl often doesn't completely clear lexical arrays on scope exit. It frees the elements of the array, but the block of memory it has to hold pointers to the 1E6 elements isn't freed. This is on the assumption that if you entered the block once and created a big array, you're likely to do so again. On the other hand, undef frees the pointer block too.

      Dave.

        So, basically, best practice would be to leave the undefs in the "startup subs" that load and parse XML configuration when the daemon is starting up, but remove them from the trigger subs that get called regularly throughout its life?