[Python-Dev] Changing pymalloc behaviour for long running processes

"Martin v. Löwis" martin at v.loewis.de
Tue Oct 19 20:09:40 CEST 2004

Evan Jones wrote:
>> Another is that the platform OS+libc may not shrink VM at
>> times even when memory is returned to the system free().
> There is absolutely nothing I can do about that, however.

You could if you wanted. Don't use malloc/free, but use
mmap/munmap, VirtualAlloc/VirtualFree, etc.

> Anyone care 
> to enlighten me?

Microsoft ships the source of its malloc(3) implementation
together with VC; you need to install the CRT source to see it.

> Let me just make sure I am clear on this: Some extensions use native 
> threads, is that why this is a problem? Because as far as I am aware, 
> the Python interpreter itself is not threaded. So how does the cyclical 
> garbage collector work? Doesn't it require that there is no execution 
> going on?

The garbage collector holds the GIL. So while there could be other
threads running, they must not manipulate any PyObject*. If they try
to, they need to obtain the GIL first, which will make them block
until the garbage collector is complete.

> It is also a waste if the core Python developers decide it is a bad 
> idea, and don't want to accept patches! :)

That will ultimately depend on the patches. The feature itself would
be fine, as Tim explains. However, patches might be rejected because:
- they are incorrect,
- their correctness cannot easily be established,
- they change unrelated aspects of the interpreter,
- they have undesirable performance properties, or
- they have other problems I can't think of right now :-)


More information about the Python-Dev mailing list