That's not quite right either. Most modern OS's have facilities for returning memory to the system (on UNIX, it's usually mmap(2)), but most software, including Perl, doesn't make good use of them. See, for example:
#!/usr/bin/perl
use constant SLEEP => 20;
warn "Starting\n";
my @arr = (1..1_000_000);
warn "Allocated\n";
sleep(SLEEP);
undef @arr;
warn "Freed.\n";
sleep(SLEEP);
Clearly most of the memory allocated will be in contiguous blocks, and could be reclaimed by the OS, but if you watch top you'll see that almost none ever is.
| [reply]
[d/l] |
perl's malloc/free keeps the memory for itself; gnu's
malloc/free may return large chunks of freed memory to the linux kernel, and the kernel usually does not absorb it instantly the cleanup is on a cycle so you may have to wait way longer than 20 seconds for the release to take effect. Mac's compiler frees to the OS as well. so it really depends what system and malloc you use when compiling perl -- however his bprogram gaining that much memory usage points to perl not reusung the pool it has and growing vars not a freeing issue.
-Waswas
| [reply] |