"Randal L. Schwartz" <merlyn@xxxxxxxxxxxxxx> wrote:
> >>>>> "Eric" == Eric Wong <normalperson@xxxxxxxx> writes:
>
> Eric> Part of it is Perl, which (as far as I know) never frees allocated
> Eric> memory back to the OS (although Perl can reuse the allocated memory for
> Eric> other things).
>
> It does on Linux, of all things. That's because Linux has a smarter
> malloc/free that uses mmap(2) for the large chunks. On Linux, Perl memory
> size can apparently grow and shrink nicely. The "old school" advice about
> Perl comes from sbrk(2)-driven malloc/free.
>
> Try:
>
> $x[1e6] = "0";
> sleep 10; # do a ps here
> @x = ();
> sleep 30; # do a ps here
>
> and watch the process on Linux. If I'm right, this should show a large
> process, then a smaller one.
Nope, not happening to me. I'm using Perl 5.8.8-7 and glibc 2.3.6.ds1-8
on a Debian Etch machine. The kernel is a vanilla 2.6.18.1 from
kernel.org.
strace shows an mmap2 call, but no corresponding mumap. I've added a
sleep loop to the end of the above program and had it print
something every 10 seconds; but so far, there's still no munmap.
while (1) {
print "hi\n" if ((time % 10) == 0);
sleep 1;
}
Trying to allocate a bigger chunk (1e7) doesn't show anything different,
either. I've also conducted similar experiments with Ruby in the past
and noticed the same things...
--
Eric Wong
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html