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 12:43:02 +0300 Message-ID: <83bmy4stax.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> <83k2cssypt.fsf@gnu.org> <6350b2df-fde9-e716-d279-9f29438f8ee5@dancol.org> <83d1ikswsf.fsf@gnu.org> <7ab47b94-c662-1351-0dd3-ed5269842438@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477647826 32101 195.159.176.226 (28 Oct 2016 09:43:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 09:43:46 +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 11:43:42 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 1c03hE-0006dh-KV for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 11:43:32 +0200 Original-Received: from localhost ([::1]:47845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c03hH-0005m7-1V for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 05:43:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c03gj-0005lq-NY for emacs-devel@gnu.org; Fri, 28 Oct 2016 05:43:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c03gf-0004o3-Pn for emacs-devel@gnu.org; Fri, 28 Oct 2016 05:43:01 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c03gf-0004ny-ME; Fri, 28 Oct 2016 05:42:57 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3880 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c03ge-0003GQ-P0; Fri, 28 Oct 2016 05:42:57 -0400 In-reply-to: <7ab47b94-c662-1351-0dd3-ed5269842438@dancol.org> (message from Daniel Colascione on Fri, 28 Oct 2016 01:44:33 -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:208933 Archived-At: > Cc: monnier@iro.umontreal.ca, eggert@cs.ucla.edu, emacs-devel@gnu.org > From: Daniel Colascione > Date: Fri, 28 Oct 2016 01:44:33 -0700 > > >> Say you have a strict-accounting system with 1GB of RAM and 1GB of swap. > >> I can write a program that reserves 20GB of address space. > > > > I thought such a reservation should fail, because you don't have > > enough virtual memory for 20GB of addresses. IOW, I thought the > > ability to reserve address space is restricted by the actual amount of > > virtual memory available on the system at the time of the call. You > > seem to say I was wrong. > > I'm not sure you're even wrong :-) What does "virtual memory" mean to > you? Physical + swap, as usual. > When we allocate memory, we can consume two resources: address space and > commit. That 100GB mmap above doesn't consume virtual memory, but it > does consume address space. Address space is a finite resource, but > usually much larger than commit, which is the sum of RAM and swap space. > When you commit a page, the resource you're consuming is commit. If reserving a range of addresses doesn't necessarily mean they will be later available for committing, then what is the purpose of reserving them in the first place? What good does it do? We have in w32heap.c:mmap_realloc code that attempts to commit pages that were previously reserved. That code does recover from a failure to commit, but such a failure is deemed unusual and causes special warnings under debugger. I never saw these warnings happen, except when we had bugs in that code. You seem to say that this is based on false premises, and there's nothing unusual about MEM_COMMIT to fail for the range of pages previously reserved with MEM_RESERVE.