What interpreters manage memory of its threads inside its own process?

I'm just wondering what interpreters manage memory of its threads insi开发者_运维知识库de its own process?

With VMware Virtual Machines, when memory is tight, VMware will inflate a "balloon" inside the VM. This allows the guest OS to "intelligently choose" what memory to swap to disk, allowing memory from that OS to be used by other VMs.

One issue is Java, where the OS can not "see/understand" the memory inside the JRE, and when the balloon inflates, the guest OS will effectively randomly swap out memory to disk and could easily swap out critical JRE functions rather than being able to intelligently choose which bits of memory to swap out.

My question is, what other interpreters behave in the same way as Java around memory management?

Is Microsoft .NET similar in this regard? Any other interpreters?

Regards ted

---

I am not sure you can selectively swap out memory used by certain threads, seeing that the main difference between a thread and a process is that they share a common memory space, and the reason to use threads over processes is that they are deemed more lightweight, precisely because you are giving up on process isolation managed by the OS.

---

So what you're really asking is, whether any interpreter implements its own algorithm for swapping data to disk. As far as I know, no interpreter designed in recent times does this - given the price of RAM nowadays, it's not a good use of engineering resources. (There is a school of thought, to which I subscribe, that says we should now consider throwing out operating system level disk swapping as well.)

Relational database systems do their own disk swapping of course, partly because they were designed when RAM was more expensive, and partly because they still sometimes deal with unusually large volumes of data.

And, memory is rusty on this one, but I could almost swear at least one of the old MUD systems also implemented its own swapping code; a big MUD could run to tens of megabytes, and in those days might have had to run in only a few megabytes of memory.