From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: Emacs bzr memory footprint Date: Fri, 21 Oct 2011 19:36:06 +0100 Message-ID: <87obxakx9l.fsf@spindle.srvr.nix> 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> <4EA1BA05.5080506@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319222178 685 80.91.229.12 (21 Oct 2011 18:36:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2011 18:36:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 21 20:36:14 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 1RHJx0-00026W-5B for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 20:36:14 +0200 Original-Received: from localhost ([::1]:60107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHJwz-0004t6-NG for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 14:36:13 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHJww-0004rY-Dp for emacs-devel@gnu.org; Fri, 21 Oct 2011 14:36:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHJwv-0002Rk-9W for emacs-devel@gnu.org; Fri, 21 Oct 2011 14:36:10 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:49573 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHJwu-0002R4-Rk for emacs-devel@gnu.org; Fri, 21 Oct 2011 14:36:09 -0400 Original-Received: from esperi.org.uk (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id p9LIa6gu016925; Fri, 21 Oct 2011 19:36:06 +0100 Original-Received: (from nix@localhost) by esperi.org.uk (8.14.5/8.14.5/Submit) id p9LIa6Jk008260; Fri, 21 Oct 2011 19:36:06 +0100 Emacs: ed :: 20-megaton hydrogen bomb : firecracker In-Reply-To: <4EA1BA05.5080506@yandex.ru> (Dmitry Antipov's message of "Fri, 21 Oct 2011 22:29:25 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-DCC-URT-Metrics: spindle 1060; Body=2 Fuz1=2 Fuz2=2 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 81.187.191.129 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:145407 Archived-At: On 21 Oct 2011, Dmitry Antipov outgrape: > 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'. They might. If sbrk() fails, mmap() is tried instead before giving up. However, in this case, resetting the mmap threshold isn't going to help: it'll try anyway. > 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). IIRC glibc malloc has always worked this way (in fact I think it worked this way even back when it was Doug Lea's malloc, before Wolfram Gloger took over maintenance). It's got less aggressive in use of mmap() over the years, but has never allocated storage below the minimum threshold except in dire straits, because mmap() is so slow. It certainly worked this way when I first looked at it back in the 2.2 days. (Though the calls are indeed harmless unless you want glibc's newer auto-weighting, which I think we probably don't for Emacs as it would make our existing fragmentation problems even worse.) --- current bloat score, holding steady: STIME TIME RSS VSZ 13:38 00:12:07 374056 561116 -- GC165 end: lisp data 173241 Kb (144386 live, 28854 free), 139720 mem nodes (6549 Kb), heap 303948 Kb used, 78115 Kb free (This sort of rising in bursts is also characteristic of heap fragmentation.)