Garbage collection

[Cameron Laird]

In article <yPcMh.12121$PL.6911 at newsread4.news.pas.earthlink.net>,
Dennis Lee Bieber  <wlfraed at ix.netcom.com> wrote:
>On Wed, 21 Mar 2007 15:32:17 +0000, Tom Wright <tew24 at spam.ac.uk>
>declaimed the following in comp.lang.python:
>
>> 
>> True, but why does Python hang on to the memory at all?  As I understand it,
>> it's keeping a big lump of memory on the int free list in order to make
>> future allocations of large numbers of integers faster.  If that memory is
>> about to be paged out, then surely future allocations of integers will be
>> *slower*, as the system will have to:
>> 
>	It may not just be that free list -- which on a machine with lots of
>RAM may never be paged out anyway [mine (XP) currently shows: physical
>memory total/available/system: 2095196/1355296/156900K, commit charge
>total/limit/peak: 514940/3509272/697996K (limit includes page/swap file
>of 1.5GB)] -- it could easily just be that the OS or runtime just
>doesn't return memory to the OS until a process/executable image exits.
			.
			.
			.
... and there *are* (or at least have been) situations where
it was profitable for an application which knew it had finished
its memory-intensive work to branch to a new instance of itself
in a smaller memory space.  That's the only, and necessarily
"tricky", answer to the question about how to make sure all that
free stuff gets back to the OS.