usually, the memory is freed by the gc to let be used again by the interpreter, but not freed to the OS. (if a malloc is called, the libc verify if there is enough space on data segment allocated by the process, if not the syscall sbrk is called to increase the data segment. i will be surprised to know that freeing enough memory could defragment it and release it to the OS, and i also suspect sbrk cannot be called to reduce it anyway)

Oha

update: after some tests, i found that allocating memory for an array will free to OS after undef-ing the array, but that will not apply to the data in the array itself:

my @x;
system "ps aux | grep $$ | grep [p]erl";
$x[1_000_000] = "foo";
system "ps aux | grep $$ | grep [p]erl";
undef @x;
system "ps aux | grep $$ | grep [p]erl";
push @x, "$_" for(1..1_000_000);
system "ps aux | grep $$ | grep [p]erl";
undef @x;
system "ps aux | grep $$ | grep [p]erl";
------
oha       8305  0.0  0.2  3296 1232 pts/0    S+   19:55   0:00 perl t4
+.pl
oha       8305  0.0  0.9  7204 5148 pts/0    S+   19:55   0:00 perl t4
+.pl
oha       8305  0.0  0.2  3296 1244 pts/0    S+   19:55   0:00 perl t4
+.pl
oha       8305 76.0  8.6 46896 44800 pts/0   S+   19:55   0:00 perl t4
+.pl
oha       8305 98.0  7.8 42796 40704 pts/0   S+   19:55   0:00 perl t4
+.pl
[download]

the mem freed to OS after the second undef is pretty close the same as the first (difference), so only the memory allocade by the strings aren't freed to OS. i still wonder why...