From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Tue, 25 Oct 2016 15:27:27 -0400 Message-ID: References: <838ttfnmev.fsf@gnu.org> <837f8znk8f.fsf@gnu.org> <83zilvm2ud.fsf@gnu.org> <83r377m0i8.fsf@gnu.org> <83eg36n6v5.fsf@gnu.org> <83shrl523p.fsf@gnu.org> <83eg354ux3.fsf@gnu.org> <83pomp35ch.fsf@gnu.org> <83eg34wfkp.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477424520 10392 195.159.176.226 (25 Oct 2016 19:42:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 19:42:00 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 21:41:56 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bz7bR-0000L7-0W for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 21:41:41 +0200 Original-Received: from localhost ([::1]:57808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz7bT-0003Ie-4Z for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 15:41:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz7No-0000jl-Tk for emacs-devel@gnu.org; Tue, 25 Oct 2016 15:27:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz7No-0006Mz-2J for emacs-devel@gnu.org; Tue, 25 Oct 2016 15:27:36 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:5397) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bz7Ni-0006LX-A3; Tue, 25 Oct 2016 15:27:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHAgALW9BX/1qOs2tdGwEBBAEBgy4BAQEBAR6ETYVQhGWrEYIDhhYEAgKBaTkUAQIBAQEBAQEBXieEYgEBAwFWIxALNBIUGA0kiFUIvFUBAQgCJYp9ihwBBJlZmQ2GC5BLHjaEbCCGCgEBAQ X-IPAS-Result: A0BHAgALW9BX/1qOs2tdGwEBBAEBgy4BAQEBAR6ETYVQhGWrEYIDhhYEAgKBaTkUAQIBAQEBAQEBXieEYgEBAwFWIxALNBIUGA0kiFUIvFUBAQgCJYp9ihwBBJlZmQ2GC5BLHjaEbCCGCgEBAQ X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="277098730" Original-Received: from 107-179-142-90.cpe.teksavvy.com (HELO ceviche.home) ([107.179.142.90]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2016 15:27:27 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 4E26266239; Tue, 25 Oct 2016 15:27:27 -0400 (EDT) In-Reply-To: <83eg34wfkp.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 25 Oct 2016 19:36:54 +0300") 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.21 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" Xref: news.gmane.org gmane.emacs.devel:208798 Archived-At: >> IIUC releasing memory with sbrk can only be done if that memory is at >> the end of the heap. > Since ralloc.c relocates blocks, it can make this happen more easily. But the sbrk area is shared with gmalloc, whose data is not relocatable, so as soon as gmalloc calls sbrk, the space previously allocated by ralloc can't be returned any more. >> > It seems ralloc is actually at an advantage, because relocating blocks >> > helps collect together a larger free block. >> mmap can always free what it has allocated before, without any need to >> relocate anything. > It makes no sense to release random pages here and there, all you get > is fragmentation at address space level. Yes, but address space is much more plentiful. Note that glibc uses exactly this approach and it works very well for us. Stefan