Check out the brk syscall. malloc is allocating more memory to itself.
You really need a custom malloc to change this behaviour. cheers, On Wed, Nov 17, 2010 at 12:53 PM, Armin Rigo <ar...@tunes.org> wrote: > 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 > _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
