Martin v. Löwis wrote:
Antoine Pitrou wrote:
Le samedi 21 juin 2008 à 17:49 +0200, "Martin v. Löwis" a écrit :
I don't think any strategies based on timing will be successful.
Instead, one should count and analyze objects (although I'm unsure
how exactly that could work).
Would it be helpful if the GC was informed of memory growth by the
Python memory allocator (that is, each time it either asks or gives back
a block of memory to the system allocator) ?
I don't see how. The garbage collector is already informed about memory
growth; it learns exactly when a container object is allocated or
deallocated. That the allocator then requests memory from the system
only confirms what the garbage collector already knew: that there are
lots of allocated objects. From that, one could infer that it might
be time to perform garbage collection - or one could infer that all
the objects are really useful, and no garbage can be collected.
I was wondering whether it might be useful to detect the end of an
allocation spike: if PyMalloc incremented an internal counter each time
it requested more memory from the system, then the GC could check
whether that number had changed on each collection cycle. If the GC goes
a certain number of collection cycles without more memory being
requested from the system, then it can assume the allocation spike is
over and tighten up the default tuning again.
Such a pymalloc counter would provide a slightly more holistic view of
overall memory usage changes than the container-focused view of the
cyclic GC.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
