From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Thu, 27 Oct 2016 23:23:05 -0700 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> <4f0c2868-d408-a5c4-d5a8-90dae750eb33@dancol.org> <878tt9ggdk.fsf@ritchie.wxcvbn.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1477635860 25560 195.159.176.226 (28 Oct 2016 06:24:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 06:24:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: eggert@cs.ucla.edu, Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 28 08:24:15 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 1c00a9-00048H-Rv for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 08:24:02 +0200 Original-Received: from localhost ([::1]:46928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c00aC-0001II-BR for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 02:24:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c00ZQ-0001GX-3f for emacs-devel@gnu.org; Fri, 28 Oct 2016 02:23:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c00ZM-00082h-AD for emacs-devel@gnu.org; Fri, 28 Oct 2016 02:23:16 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:42502) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c00ZM-00082J-1F; Fri, 28 Oct 2016 02:23:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=xXsiuFf/ITcc0Vr9lEdMSZ8Zghj0wJ1bnXAwd5DPCes=; b=KfzZ1n9omVzSVYa4zDoh4YueBbbwWtjEP6ycMHbJHNftaWc/Unu7D2w3vN7gYhzI1PzkV59tzTVsd5mfBnZ2khwcJy3wFEoljmSKfOPV9fbAFxEB52Z+nSNFrU8NIM54wriIZJghgT+T3trPTlXe6xhTU1bwKa3MW2G5DoP4iFk2OIQcLMSX7Z/bSTIQUah0ELoxQr11HtjZt0xOINv17RrvjjAs+pBtrL/5ckJPOQ4hc36HS8/xBaROSmjM3HWJ50m+SgJeATGX8t2KI57K7RUmVYIJgy9Q3+/zHKzi9mgLIzf4OqxPtxAJKNoj4pxdkrnPI8lT9DpWlVyrzvlJcg==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1c00ZJ-0003xt-L3; Thu, 27 Oct 2016 23:23:09 -0700 In-Reply-To: <878tt9ggdk.fsf@ritchie.wxcvbn.org> (=?utf-8?Q?=22J=C3=A9r?= =?utf-8?Q?=C3=A9mie_Courr=C3=A8ges-Anglas=22's?= message of "Fri, 28 Oct 2016 08:03:03 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:208915 Archived-At: jca@wxcvbn.org (J=C3=A9r=C3=A9mie Courr=C3=A8ges-Anglas) writes: > Daniel Colascione writes: > >> On 10/24/2016 08:40 AM, Eli Zaretskii wrote: >>>> From: Stefan Monnier >>>> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org >>>> Date: Mon, 24 Oct 2016 10:37:19 -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. >> >> 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. > > IIUC you suggest relying on memory overcommit. That doesn't sound > portable at all. Not all OSes do overcommit and the ones who do > generally provide a way to disable it. You understand incorrectly. "Overcommit" is the practice of allowing an operating system to lie about how much memory it's guaranteed to give applications in the future. We're not talking about guaranteed memory. We're talking about setting aside address space only, not asking the OS to make guarantees about future memory availability. All major operating systems, even ones like Windows that don't do overcommit, provide ways to reserve address space without asking the OS to guarantee availability of memory. That said, my idea probably isn't the best --- but it doesn't rely on overcommit.