From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Mon, 24 Oct 2016 22:38:22 +0300 Message-ID: <83pomp35ch.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477338432 30769 195.159.176.226 (24 Oct 2016 19:47:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 19:47:12 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 21:47:08 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 1bylCo-0004qg-EO for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 21:46:46 +0200 Original-Received: from localhost ([::1]:49483 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bylCq-0001iX-SY for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 15:46:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byl51-0003cL-QK for emacs-devel@gnu.org; Mon, 24 Oct 2016 15:38:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byl4z-0002pM-7C for emacs-devel@gnu.org; Mon, 24 Oct 2016 15:38:43 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byl4z-0002pE-3f; Mon, 24 Oct 2016 15:38:41 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3522 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byl4w-0001PY-7g; Mon, 24 Oct 2016 15:38:40 -0400 In-reply-to: (message from Stefan Monnier on Mon, 24 Oct 2016 14:45:59 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:208740 Archived-At: > From: Stefan Monnier > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Mon, 24 Oct 2016 14:45:59 -0400 > > >> > 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)? Visiting a large compressed file (e.g., an Emacs release tarball compressed with gzip) takes with mmap several times as long as in a build without mmap. > > 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. How so? Releasing memory in both cases requires basically the same situation: a large enough block of contiguous memory not in use. It seems ralloc is actually at an advantage, because relocating blocks helps collect together a larger free block.