On Wed, Jan 8, 2014 at 3:30 PM, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > The garbage collector has nothing to do with the memory usage of immutable > types like ints. There are deallocated instantly when the last reference you > hold is cleared (in CPython). So if you run out of memory because of them > then it is because you're keeping them alive in your own code. Running the > garbage collector with gc.collect cannot help with that.
Object deallocation in CPython doesn't necessarily free memory to the system. A deallocated object can go on a freelist, or it could have been allocated out of an obmalloc arena that persists. Either way this can lead to to a heap high-water mark. 3.3 avoids this wrt obmalloc by using POSIX mmap instead of malloc, and 3.4 uses Windows VirtualAlloc (whereas malloc uses HeapAlloc). It doesn't need malloc to manage small blocks; that's its job after all. Calling gc.collect(generation=2) will clear freelists for several built-in types, which may enable the heap to shrink if there's a high-water mark lingering in a freelist. This is mostly a concern prior to 3.3. float was the last holdout. It used the original freelist design until 3.3. Per issue 14435 it was transitioned to using obmalloc. The old float freelist was the same design as the one for 2.x int (PyInt, not PyLong), which grows without bound. The design also allocates objects in 1 KiB blocks (approx. size). glibc's malloc will use the heap for a block that's this small. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
