From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: (heap 1024 82721 1933216) Date: Sat, 18 Jan 2014 21:53:26 -0500 Message-ID: References: <52DA8412.2080009@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390100020 13772 80.91.229.3 (19 Jan 2014 02:53:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 02:53:40 +0000 (UTC) Cc: Emacs developers To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 19 03:53:46 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4iWA-0001xo-AV for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 03:53:46 +0100 Original-Received: from localhost ([::1]:44943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iW9-00016Y-Ql for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 21:53:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iVz-00016O-S2 for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:53:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4iVs-0005Dm-Ie for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:53:35 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:7868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iVs-0005Di-F6 for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:53:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCplR/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZcHhRKBXoMV X-IPAS-Result: Av8EABK/CFFMCplR/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZcHhRKBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45288264" Original-Received: from 76-10-153-81.dsl.teksavvy.com (HELO pastel.home) ([76.10.153.81]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Jan 2014 21:53:27 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 03DA5603BA; Sat, 18 Jan 2014 21:53:26 -0500 (EST) In-Reply-To: <52DA8412.2080009@dancol.org> (Daniel Colascione's message of "Sat, 18 Jan 2014 05:39:30 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:168715 Archived-At: > value. dlmalloc's free memory retention seems a bit severe here. There are several levels at which the memory is "returned to the other level": - if a single cons cell is in use in a "cons cell block", that block can't be freed. - those blocks are themselves allocated in groups of 16 IIRC, so those groups can only be freed once all 16 of them have been freed at the previous level. - malloc/free can itself decide to keep those "freed" blocks for later use, or to return them to the OS. At this level, the behavior depends on the malloc library in use, which depends on the OS. IIUC there are malloc libraries in use which never return memory back to the OS. > Are we just badly fragmenting the heap? Could be. For an Emacs that grew to 6GB, I don't find it worrisome if it doesn't shrink back below 2GB. I'm much more worried about: how on earth did it grow to 6GB? Stefan