The memory cleanup on perl's exit, is a whole other type of cleanup I'm afraid. Perl allocates a bunch of memory from the OS, but the problem is in how it uses this memory itself. The memory is returned to the OS at perl exit offcourse.

Doing the same kind of cleanup without exiting perl would probably not be a trivial change to perl. Just an example of a problem you'd encounter would be how to handle the special global variables that are linked to the perl parameters from the shebang (#!) line...

A bigger problem though, would be that cleaning up all of the memory would mean all modules would have to be reloaded too, and the module loading and initialisation is often even slower then the perl interpreter loading...

As a perl module can change variables in *any* namespace, so we can't just clear the part of the namespace it's using, and keep it loaded. There is just no proper way to 'reset' a running perl to initial state. The 'flow' of compilation can change, because of the existence of stuff like BEGIN blocks, so the line between compilation time and runtime can get blurry. This makes resetting perls internal state even harder...

It's for these reasons that mod_perl has the complexity is has, and that the programmer needs to be aware of the persistent behaviour some variables may exhibit. There's just no way around it I'm afraid... Not without removing a ton of functionality from perl itself, which in turn would break half the modules out there that people are using.

It's a hard subject to explain without getting into deep technical detail, but I hope I've hinted in the right direction...