[Tutor] garbage collecting

[eryksun]

On Wed, Jan 8, 2014 at 3:30 PM, Oscar Benjamin
<oscar.j.benjamin at 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.