From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Replacing malloc_get_state functionality. Date: Tue, 4 Mar 2014 11:31:20 +0100 Message-ID: <20140304103120.GA11790@domone.podge> References: <20140220232941.GA2929@domone.podge> <53070258.5090804@cs.ucla.edu> <530BDB13.5040601@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1393929097 21190 80.91.229.3 (4 Mar 2014 10:31:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Mar 2014 10:31:37 +0000 (UTC) Cc: Andreas Schwab , Paul Eggert , Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 04 11:31:45 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 1WKmdT-00007W-Q8 for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 11:31:43 +0100 Original-Received: from localhost ([::1]:44084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKmdT-0001xs-DP for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 05:31:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKmdL-0001xH-Mz for emacs-devel@gnu.org; Tue, 04 Mar 2014 05:31:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKmdD-0000al-2x for emacs-devel@gnu.org; Tue, 04 Mar 2014 05:31:35 -0500 Original-Received: from popelka.ms.mff.cuni.cz ([195.113.20.131]:51632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKmdC-0000aC-Rj for emacs-devel@gnu.org; Tue, 04 Mar 2014 05:31:26 -0500 Original-Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id 120594646; Tue, 4 Mar 2014 11:31:21 +0100 (CET) Original-Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id 702005F96B; Tue, 4 Mar 2014 11:31:21 +0100 (CET) Content-Disposition: inline In-Reply-To: <530BDB13.5040601@dancol.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.97.8 at popelka.ms.mff.cuni.cz X-Virus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 195.113.20.131 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:170130 Archived-At: On Mon, Feb 24, 2014 at 03:51:47PM -0800, Daniel Colascione wrote: > 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)? >=20 > Based on comments in the code, I'm not sure Emacs can operate > correctly using the system dlmalloc without malloc_set_state: >=20 > /* 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. */ >=20 > 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. >=20 > 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.) >=20 > 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. >=20 > 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. >=20 > Ond=C5=99ej, are you planning on adding fragmentation resistance to the > glibc malloc? Yes, but there is lower hanging fruit around. Most noticable would be memory savings from omitting headers, currently we add 16byte overhead per allocation.