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: Fri, 28 Oct 2016 10:46:06 +0300 Message-ID: <83k2cssypt.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477640827 26812 195.159.176.226 (28 Oct 2016 07:47:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 07:47:07 +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 Fri Oct 28 09:47:03 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 1c01sN-0005HS-FL for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 09:46:55 +0200 Original-Received: from localhost ([::1]:47281 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c01sP-00013O-Of for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 03:46:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c01rZ-00012b-VG for emacs-devel@gnu.org; Fri, 28 Oct 2016 03:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c01rW-0002hb-0g for emacs-devel@gnu.org; Fri, 28 Oct 2016 03:46:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c01rV-0002hV-PU; Fri, 28 Oct 2016 03:46:01 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3718 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c01rU-0007Cd-VZ; Fri, 28 Oct 2016 03:46:01 -0400 In-reply-to: (message from Daniel Colascione on Thu, 27 Oct 2016 23:23:05 -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:208926 Archived-At: > From: Daniel Colascione > Cc: Stefan Monnier , eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Thu, 27 Oct 2016 23:23:05 -0700 > > 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. Not sure I understand you: if a portion of the address space has been reserved, how come these addresses won't be available when we try to commit them later? There might not be physical pages available for that, but virtual memory for those addresses must be available, no?