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 19:57:53 +0300 Message-ID: <83vawh3cry.fsf@gnu.org> References: <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <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> <4f0c2868-d408-a5c4-d5a8-90dae750eb33@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477328508 23667 195.159.176.226 (24 Oct 2016 17:01:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 17:01:48 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 19:01:43 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 1byicZ-00023z-4z for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 19:01:11 +0200 Original-Received: from localhost ([::1]:48264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byicb-00027w-ET for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 13:01:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiZY-0005gn-4z for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:58:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byiZT-0002YN-US for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:58:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiZT-0002YB-S2; Mon, 24 Oct 2016 12:57:59 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3282 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byiZS-0004QK-Kn; Mon, 24 Oct 2016 12:57:59 -0400 In-reply-to: <4f0c2868-d408-a5c4-d5a8-90dae750eb33@dancol.org> (message from Daniel Colascione on Mon, 24 Oct 2016 09:27:43 -0700) 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:208729 Archived-At: > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 24 Oct 2016 09:27:43 -0700 > > >>> 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. > > 64-bit address spaces are *huge*. What about just making every buffer > allocation 2GB long or so, marked PROT_NONE? You don't actually have to > commit all that memory --- all you've done is set aside that address > space. But because you've set aside so much address space, you'll very > likely be able to expand the actual allocation region (a subset of the > reserved region) as much as you want. Sounds OK, although I'm not an expert on that. But in any case, these ideas are not baked enough to be applied to the release branch, if we want to release Emacs 25.2 soon (as in "in a couple of months"). (Of course, there's always the case of a file larger than 2GB, it's not unheard of, although still quite rare.)