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: Mon, 24 Oct 2016 14:45:59 -0400 Message-ID: References: <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477336863 2795 195.159.176.226 (24 Oct 2016 19:21:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 19:21:03 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 21:20:58 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 1byknV-0006Ao-2t for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 21:20:37 +0200 Original-Received: from localhost ([::1]:49248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byknV-0005Le-W3 for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 15:20:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bykGF-0002br-9u for emacs-devel@gnu.org; Mon, 24 Oct 2016 14:46:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bykGA-00032k-Bj for emacs-devel@gnu.org; Mon, 24 Oct 2016 14:46:15 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bykGA-00032M-5m; Mon, 24 Oct 2016 14:46:10 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u9OIjxjL016927; Mon, 24 Oct 2016 14:45:59 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 11C376047D; Mon, 24 Oct 2016 14:45:59 -0400 (EDT) In-Reply-To: <83eg354ux3.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Oct 2016 18:40:40 +0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV5837=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5837> : inlines <5363> : streams <1717467> : uri <2314031> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:208738 Archived-At: >> > Using mmap has disadvantages: when you need to enlarge buffer text, >> > and that fails (because there are no more free pages/addresses after >> > the already allocated region), we need to copy buffer text to the new >> > allocation. >> All allocators suffer from this problem. I haven't seen any evidence >> that the mmap-based allocation code is significantly more prone to it. > I have seen that. Could you give some details (mostly about the scale of the problem)? > The native glibc malloc, the on GNU/Linux systems were using until we > got screwed by the recent glibc, didn't have this problem, while > mmap-based allocator did. Don't ask me how glibc does it, I don't > know; but the fact is there. It likely mmaps a bit more than requested, like you do in w32heap.c. >> Another advantage of using mmap is that it can return the memory to the >> OS once you kill your large buffer, whereas with gmalloc+ralloc this >> basically never happens, AFAIK. > Not entirely true: ralloc calls the system sbrk with a negative > argument when it feels like it. That's why I said "basically". Yes, in theory it can sometimes return memory. In practice, this is rare. In contrast, with mmap, returning memory to the OS is the rule rather than the exception. Stefan