I guess what you are saying is this is basically just how memory management is in PERL?

It's not: "how memory management is in Perl"; it's: how memory management is!

In general, it is expensive for a process to request more memory from the OS; so once a process (via your C compiler memory management functions) have requested memory from the OS, they are reluctant to give it back because it would be expensive to re-request it from the OS again. Better to simply keep it around until the next time it is needed.

This is, for the most part, the way all memory managers work.

How else would you deal with a long running application using threads not eating up all the memory?

I'll say it again. There is no problem with running many dozens of concurrent threads. With 512MB, based on the numbers you gave above, you should be able to run ~50 threads concurrently without problems.

And so long as no more than 50 are ever running at any given time; you should be able to start & end thousands of threads without ever breaking that same limit.

But whether it is a good idea to do so is a different question that can only be answered by seeing your code.

It is not the number of threads you start; nor how long the process runs for that is the limiting factor; but rather the number of them that are running at the same time. It's not rocket science to see that the more you run concurrently; the more memory it will use. Use too many at the same time and you'll run out of a finite resource.

Threads are killed using a signal which calls threads->exit().

Killing threads is a really bad idea; and IS likely to cause memory leaks.