Swap is slow? Have you benchmarked it? I would be willing to bet 1,000 XP (if I could) against that assumption. Hard disks nowadays are incredibly fast - not as fast as RAM, but fast nonetheless. On my 4-year-old machine, where I had 4GB RAM, I wouldn't really notice the swapping until I got to about 2 or 3GB of swap used, and it only got unnerving when I was sitting over 4GB of swap in use. On my current machine (set up in May, 2008), with 8GB RAM, I haven't noticed any significant impact to responsiveness sitting at 3 or 4 GB of swap used. (Of course, the next question is what the heck I'm doing with that much RAM in use on my desktop, but that's another topic.) In short, I don't believe your claim that swap is slow.

Second, I did propose a solution to your problem: exit. As in, do all your hard work in a subprocess, and when it exits, its memory is reclaimed. That's how the operating system works. The reason why you can't just return no-longer-needed memory back to the OS is simple: the OS authors know what you apparently don't believe: swap is NOT slow. It's generally faster for the system as a whole to swap out unused memory when/if it needs additional memory than it is to re-allocate it later. Of course, I said generally, so if benchmarks actually show that your system would run faster with reclamation of memory, there is a way: exit from the subprocess that is actually using the memory. (That doesn't mean swap is slow - just slower than the alternative of exiting.)

Calling an actual solution "a workaround" is merely semantics trying to denigrate the solution proposed. They mean the same thing, with differing interpretations of elegance. I just happen to not agree with you that freeing memory to the OS is any more elegant for most applications. It's going to be extremely rare that an application knows the system memory usage better than the kernel. The far more elegant solution is buying more RAM or increasing swap space (or both). It allows developers to spend more time worrying about important things like functionality. Of course, here I'm assuming legitimate use for the memory, and not a memory leak (where no amount of RAM or swap space will suffice over time).