Hi, (Answering here in addition to on IRC, for reference.)
On Wed, Nov 10, 2010 at 9:53 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: > * 31M of mmaped code blocks for assembler > * about 150M I can account for that is jit resume data > * about 150M of the rest I can account for. > > Where is everything else? Can GC trash some memory (like a lot). Everything else is memory that has been freed, but not returned to the OS. (You get the same effect with CPython 2.5.) That's a bit unexpected, because we call the C-level free() on it, but it is still not returned to the OS; it seems to be caused by only a few mallocs() that occur from time to time and stay alive for long (e.g. a few 4KB pages needed by the GC for its various AddressStacks). I verified it in a custom C program that does the same calls to malloc() and free(). If at the end we force free() on the remaining few 4KB blocks, then the total memory use suddenly drops from (in this example) more than 200MB to almost 0. This seems to be the main difference between the way pypy-c and CPython 2.6 call the C-level malloc() and free(). Unsure how to fix it. (If the same program then asks for more memory again, it will reuse this memory -- the libc malloc() at least ensures this, of course.) A bientôt, Armin. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
