tim.peters at gmail.com
Mon Sep 20 07:35:31 CEST 2004
[benevilent at optusnet.com.au]
> My latest understanding is that the default memory allocation will result
> in arenas being created to fulfill the maximum memory requirements of the
I'm not sure what that means, but probably yes.
> If memory is freed, the program still occupies the amount of
> memory occupied by these arenas.
It's true that pymalloc never returns an arena to the system free().
It's also true, e.g., that space allocated for Python integers never
leaves a special internal free list for integers until Python shuts
down, and pymalloc plays no part in that.
> If allocations can be fulfilled without creating new arenas, then no additional
> memory will be required.
Not all parts of Python use pymalloc. If you're talking only about
the parts that do use pymalloc, then yes.
> Hence as time goes by the memory required by the program increases
> (assuming increasing memory requirements of the application), and it will not
> dynamically expand and contract with the memory allocations/deallocations
> as you would expect with an ordinary program. Is my understanding of this
Possibly. I personally don't expect simplistic behavior from programs
that use only malloc and free, assuming that's what "an ordinary
program" intends to mean here. The relationship between the platform
malloc/free and "memory required by the program" is usually very
complex. Throwing pymalloc into the mix too makes it even more
complex. "memory required by the program" is ambiguous on its own on
machines with virtual memory, due to distinguishing between RAM in use
and paged-out virtual address space that's never referenced again.
[... later ...]
> Is it possible to change the memory allocation scheme of Python so that I
> can confirm this?
You can build Python without pymalloc. I've never done that myself,
so am not sure how to do it. Could be that passing --with-pymalloc=no
More information about the Python-list