On 2007-07-16 00:58, Jeff Rush wrote:
Hrvoje Niksic wrote:
Alexey Nezhdanov email@example.com writes:
But, barring a bug in Python, that is exactly the situation you would be in if you didn't reinitialize the interpreter in the first place.
ok, thanks. Still it may be ok for my purposes if I can keep python from growing forever and just keep it beneath some limit.
But Python should behave like that anyway. If your Python is "growing forever", it means that there is a bug in Python, or in the code using it incorrectly.
A different but somewhat related problem with Python is that the underlying C memory manager does not release memory back to the operating system when Python releases it to the memory manager. This leads to a situation where you have a momentary need for more memory, say at startup, and then you drop back down in usage but never give that memory to other apps.
This is a known problem with the use of Python in embedded devices such as the One-Laptop-Per-Child and the OpenMoko cell phone. I've heard rumors that someone is looking at it, especially because of the OLPC project but have no other information.
The Parrot/Pynie project (Python on top of the Perl6 engine) is using memory pools and mark/sweep so they can rearrange objects behind the scenes and release pools back to the OS. Not that that helps us cPython users of course, but I thought it interesting.
Python 2.5 does the same. Tim Peters (AFAIR) applied some changes to pymalloc to make this possible.
Note that you can tune pymalloc using various parameters you can tweak (see obmalloc.c) and even switch it off if you need the OS to be in complete control. Doing so will slow the interpreter considerably.
Also note that quite a few object implementations use free lists which are not easy to tweak in this way.