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 22:29:25 +0400 Message-ID: <4EA1BA05.5080506@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> <4EA18204.4010604@yandex.ru> <87sjmml689.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 1319221786 30239 80.91.229.12 (21 Oct 2011 18:29:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2011 18:29:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nix Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 21 20:29:42 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 1RHJqg-0007K3-1l for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 20:29:42 +0200 Original-Received: from localhost ([::1]:51050 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHJqf-0002Jv-Gx for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 14:29:41 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHJqa-0002JV-Hp for emacs-devel@gnu.org; Fri, 21 Oct 2011 14:29:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHJqY-0000ql-Sl for emacs-devel@gnu.org; Fri, 21 Oct 2011 14:29:36 -0400 Original-Received: from mail.dev.rtsoft.ru ([213.79.90.226]:33809) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RHJqX-0000q1-SH for emacs-devel@gnu.org; Fri, 21 Oct 2011 14:29:34 -0400 Original-Received: (qmail 22266 invoked from network); 21 Oct 2011 18:29:31 -0000 Original-Received: from unknown (HELO ?192.168.5.146?) (192.168.1.70) by 0 with SMTP; 21 Oct 2011 18:29:31 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 In-Reply-To: <87sjmml689.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:145406 Archived-At: On 10/21/2011 07:22 PM, Nix wrote: > Really? I double-checked the glibc-2.12 malloc source Hmm... I didn't check the sources and didn't any tests, but info manual from 2.14 says: `M_MMAP_THRESHOLD' All chunks larger than this value are allocated outside the normal heap, using the `mmap' system call. This way it is guaranteed that the memory for these chunks can be returned to the system on `free'. Note that requests smaller than this threshold might still be allocated via `mmap'. That's why Emacs uses mallopt (M_MMAP_MAX, 0) each time before allocating chunks for Lisp data - this effectively says 'no more mapped areas please', regardless of the requested size. The manual may be outdated, so I'll check this too. If you're right, these calls of mallopt (M_MMAP_MAX, 0) becomes redundant with never glibcs (but still should present for compatibility with old versions). Dmitry