Perl never hands memory back to the operating system. It's not Perl's fault, it's the way memory works in most modern operating systems. When Perl reaps an object, the memory is free for Perl to use again, but not free for Excel or XFree to use until Perl exits.
Some day we'll manage to stomp this particular meme out, as it's based on a misfeature originally wired into Unix, one that has been fixed for quite a number of years for most versions. Modern operating systems do give memory back to the system, and older operating systems (Unix, remember, is 33 -- hardly modern) with recent versions generally do as well.
| [reply] |
I think this is quibbling over semantics; where one may start to say things like "memory is not RAM." This actually depends on how you look at it.
This is my understanding, which may be out of date. I'm always up for a fresher course in modern operating system design.
From the application, and its itinerant malloc()'s point of view, the memory space is a contiguous resource and once available, is always available. From the kernel's point of view, RAM pages that have not been accessed lately may be cached to some persistent store and then repurposed for other processes with a new virtual address. However, malloc() may choose to revisit that once-free()'d range and then the kernel needs to arrange some RAM to match it. A process which frees a chunk of memory in the middle of its address range does not shrink on the process list accounting; instead, the kernel over-books the RAM for multiple processes needing memory, and thrashes when the over-booking becomes significant enough that processes are contending for more RAM than is physically available.
--
[ e d @ h a l l e y . c c ]
| [reply] |
No, it isn't quibbling over semantics. Nearly all operating systems have facilities to unmap pages from a process' memory space and give them back to the OS. Not swap them out, not ignore them and let them get compressed, give them back. VMS, Win32, MacOS, OS/3x0 (which is rather older than Unix), AmigaOS, RSTS/E, RSX, RT-11. (I believe TOPS-10 and TOPS-20 did as well, but I'm not positive) Unix was, for quite a while, relatively rare in the multi-user OS realm as a system that wouldn't unmap pages, though the general design of Unix programs minimized the annoyance it caused.
Even still, Most Unix and Unix-like systems have caught up with the '80s and will, in fact, unmap pages, freeing them back to the OS and taking them out of the process' memory space. Perl will give back space to the OS if the OS or C libraries support that and a memory block is unused.
Generally speaking, there's nothing wrong with having a series of discontiguous memory chunks mapped into a process. Happens all the time on many systems, and it works just fine. (Holes in mapped address space actually make a number of things mildly safer, which is also nice)
| [reply] |