From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: Emacs bzr memory footprint Date: Fri, 21 Oct 2011 18:30:28 +0400 Message-ID: <4EA18204.4010604@yandex.ru> References: <83fwix2osa.fsf@gnu.org> <0B3EE7A4-D0D6-4D1E-ADC4-0BEE68F179B2@mit.edu> <87fwivwp37.fsf@turtle.gmx.de> <87sjmvpmd2.fsf@lifelogs.com> <87aa93wmc4.fsf@turtle.gmx.de> <87sjmnrdjw.fsf@spindle.srvr.nix> <87ty73mc0m.fsf@spindle.srvr.nix> <83aa8usqnt.fsf@gnu.org> <877h3ymtwp.fsf@spindle.srvr.nix> <831uu6seqk.fsf@gnu.org> <87y5weo6jc.fsf@spindle.srvr.nix> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1319207447 20773 80.91.229.12 (21 Oct 2011 14:30:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2011 14:30:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 21 16:30:44 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RHG7O-0007lR-7R for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 16:30:42 +0200 Original-Received: from localhost ([::1]:40917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHG7N-0003yy-71 for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 10:30:41 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHG7K-0003ys-FJ for emacs-devel@gnu.org; Fri, 21 Oct 2011 10:30:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHG7J-0004zx-5a for emacs-devel@gnu.org; Fri, 21 Oct 2011 10:30:38 -0400 Original-Received: from mail.dev.rtsoft.ru ([213.79.90.226]:41956) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RHG7I-0004zW-N1 for emacs-devel@gnu.org; Fri, 21 Oct 2011 10:30:37 -0400 Original-Received: (qmail 9795 invoked from network); 21 Oct 2011 14:30:33 -0000 Original-Received: from unknown (HELO ?192.168.5.146?) (192.168.1.70) by 0 with SMTP; 21 Oct 2011 14:30:33 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 In-Reply-To: <87y5weo6jc.fsf@spindle.srvr.nix> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 213.79.90.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145394 Archived-At: 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