[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs bzr memory footprint

From: Dmitry Antipov
Subject: Re: Emacs bzr memory footprint
Date: Fri, 21 Oct 2011 18:30:28 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

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

On GNU/Linux system, Emacs tweaks this default with mallopt (M_MMAP_THRESHOLD, 

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]