From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Replacing malloc_get_state functionality. Date: Mon, 24 Feb 2014 15:51:47 -0800 Message-ID: <530BDB13.5040601@dancol.org> References: <20140220232941.GA2929@domone.podge> <53070258.5090804@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1393285937 12016 80.91.229.3 (24 Feb 2014 23:52:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2014 23:52:17 +0000 (UTC) Cc: =?UTF-8?B?T25kxZllaiBCw61sa2E=?= , emacs-devel@gnu.org, Paul Eggert To: Stefan Monnier , Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 00:52:25 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 1WI5Jx-0007Er-4r for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 00:52:25 +0100 Original-Received: from localhost ([::1]:60275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI5Jw-0000PT-Q0 for ged-emacs-devel@m.gmane.org; Mon, 24 Feb 2014 18:52:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI5Jo-0000PK-E2 for emacs-devel@gnu.org; Mon, 24 Feb 2014 18:52:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WI5Jh-0005oO-5t for emacs-devel@gnu.org; Mon, 24 Feb 2014 18:52:16 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:47132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI5Jg-0005nS-RV for emacs-devel@gnu.org; Mon, 24 Feb 2014 18:52:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/EE68tQjVL8v8HSkMfZ6CShqcN3TKir8pMQOJKmFVno=; b=YRg1zOIT4Jd2mk9L3J+0JCovUG0qXHgvpAPHjeBK+KP+0/Eq/tDWO1oyIZX+wHr9DKN/5qx82l3xFK8SwIclUThKaEl4v5H9QzOxfoWcCCYinge9CF+4qUejxCqXLuqOxuTNUs04N5O605hohbA0txhsJZL1mVJbL/BjmI8VqEMXryOg8LqooGa1idXoSxmfIRJmgXmEhLBgvWB9LpS91CrohEcn58h8G3/L6axWU+yrE9eVH4PTLKIly2Y36e4huBPxlDCWUtRfMwbfM1LXwbDOLRi4A7G1ar/Ka6gnn4AcBpJs6lQZrD4KQjWXc9RgvY0TbE3O5MKC3lPtSI7Uhg==; Original-Received: from 66-192-186-66.static.twtelecom.net ([66.192.186.66] helo=[172.26.194.181]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WI5JT-0006wZ-MD; Mon, 24 Feb 2014 15:51:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:169853 Archived-At: On 02/24/2014 12:01 PM, Stefan Monnier wrote: >>> This tells 'configure' to assume that malloc_get_state does not work. >> Does it still work, though? > > And doesn't this have some impacts in terms of Emacs's memory use > (e.g. retaining more memory instead of returning it via munmap)? Based on comments in the code, I'm not sure Emacs can operate correctly using the system dlmalloc without malloc_set_state: /* malloc can be invoked even before main (e.g. by the dynamic linker), so the dumped malloc state must be restored as early as possible using this special hook. */ When DOUG_LEA_MALLOC is unset, we skip some other heap manipulations (like restrictions on mmap allocation of lisp objects) that seems essential for correctness. After the feature freeze, I'd like to look into moving Emacs away from sbrk-based allocators in general. It's tremendously wasteful of commit charge to keep a large data segment around. (Yes, GNU/Linux systems typically overcommit memory, which lessens the impact of the waste. Two wrong don't make a right.) jemalloc works very well for other long-running programs (like Firefox), and although good support for concurrent allocation is one of jemalloc's main selling points, its fragmentation avoidance features are actually much more attractive to me right now. This work will require breaking support on all platforms for dumping a dumped Emacs, but I'm not aware of any platform on which this feature works anyway. Ondřej, are you planning on adding fragmentation resistance to the glibc malloc?