Re: Emacs bzr memory footprint

[Dmitry Antipov]

On 10/21/2011 04:47 PM, Nix wrote:

> Unfortunately it won't release memory back to the OS in the situation I
> described. mmap() is expensive, so only large allocations (by
> default>128Kb or>512Kb depending on glibc version and arch) get
> mmap()ed.

On GNU/Linux system, Emacs tweaks this default with mallopt (M_MMAP_THRESHOLD, 
64*1024).

Nevertheless, glibc malloc design assumes that smaller (below threshold above) 
chunks may
be still allocated with mmap(). Run emacs with:

strace -e signal=none -e trace=mmap,mremap,munmap emacs

and you will see a lot of allocation requests of very different sizes.

On the other side, lisp data is newer mapped, and in some cases this is the 
main reason
which causes sbrk()'ed heap fragmentation. Don't beat toolkits, don't beat 
system libraries.
Now I'm observing the case where 4 GCs reduces amount of lisp data (live + free 
lists) from
30M to 8M, and mallinfo().fordblks raises from 1M to 22M. This 21M of 
fragmented heap
is 'locked' into malloc freelists; they can be re-used, but will never released 
back to OS.

Dmitry