This isn't necessary. On some operating systems, Windows included, perl will release blocks of free memory back to the system when it's done with them. There are some limitations on this that you have basically no control over, but if you're running Win32, MacOS, VMS, or with some versions of glibc, memory will get released back to the system (not just back to the process' free pool) when it is completely unused.
in reply to make perl release memory
This process isn't guaranteed. For a chunk of memory to be released it must be of sufficient size to be worth it (glibc puts a minimum allocation size somewhere in the megabyte range to trigger allocation of a releaseable segment) and it must be completely empty. If the allocation size is too small what'll happen is that a larger block will be allocated and parcelled out in pieces by the C library. This larger block will often (though not always) be releasable, but since it's been carved into a zillion little pieces it rarely will ever be completely unused and thus released. Some systems also place a minimum hold time of some sort on the chunks, and won't release them immediately in case space is needed, to save the time spent freeing and then reallocating the space.
Basically if you allocate 100M in one chunk, it'll get released back to the system when unused. If you allocate 100M in 100 byte chunks, it'll never get released.
There's not much you can do with the current perl 5 source to make this happen any differently. Perl already does the right thing, and its up to the system and runtime libraries to decide whether chunks should be released. Unfortunately interpreters are rather complex beasts and making things work differently is a non-trivial and counterintuitive process.