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 13:47:35 +0100 Message-ID: <87y5weo6jc.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319201274 8374 80.91.229.12 (21 Oct 2011 12:47:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 21 Oct 2011 12:47:54 +0000 (UTC) Cc: jwiegley@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 21 14:47:50 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 1RHEVo-000263-Fs for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 14:47:48 +0200 Original-Received: from localhost ([::1]:49755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHEVn-0002pm-KO for ged-emacs-devel@m.gmane.org; Fri, 21 Oct 2011 08:47:47 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHEVj-0002pP-O8 for emacs-devel@gnu.org; Fri, 21 Oct 2011 08:47:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHEVi-0007HY-Jb for emacs-devel@gnu.org; Fri, 21 Oct 2011 08:47:43 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:48887 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHEVf-0007Gn-DN; Fri, 21 Oct 2011 08:47:39 -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 p9LClZEn015067; Fri, 21 Oct 2011 13:47:35 +0100 Original-Received: (from nix@localhost) by esperi.org.uk (8.14.5/8.14.5/Submit) id p9LClZ3i003371; Fri, 21 Oct 2011 13:47:35 +0100 Emacs: the answer to the world surplus of CPU cycles. In-Reply-To: <831uu6seqk.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 21 Oct 2011 14:36:51 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-DCC-STAT_FI_X86_64_VIRTUAL-Metrics: spindle 1245; Body=3 Fuz1=3 Fuz2=3 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:145389 Archived-At: On 21 Oct 2011, Eli Zaretskii said: >> Date: Fri, 21 Oct 2011 13:05:42 +0100 >> What, even if what's happening is massive allocation of conses followed >> by allocation of longer-lived stuff followed by freeing of those conses? > > I'm really not an expert on this, but I think the answer is YES. At > least the GNU/Linux build does not use the gmalloc.c and ralloc.c > modules, AFAIK because the native malloc on GNU/Linux includes the > same or superior functionality. 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. If you want to e.g. release all storage allocated for a buffer *and its local variables* when that buffer is freed, you need a pool allocator which can be told to allocate those local variables in a buffer-specific mmap()ed pool... and glibc malloc has nothing like it. (I'm thinking here of something like APR's pool allocators, though obviously not actually those allocators. Something with a similar design though.) But this is all speculation. I'm running a debugging patch now courtesy of Dimitry Antipov: we'll see what it turns up in the next few days (or even possibly hours). -- NULL && (void)