From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: jca@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Fri, 28 Oct 2016 16:41:26 +0200 Message-ID: <87wpgscz8p.fsf@ritchie.wxcvbn.org> References: <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> <87vawcem79.fsf@ritchie.wxcvbn.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477665865 21697 195.159.176.226 (28 Oct 2016 14:44:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 14:44:25 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 28 16:44:13 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 1c08Nu-0002Fz-Mj for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 16:43:54 +0200 Original-Received: from localhost ([::1]:49564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c08Nx-0001dc-85 for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2016 10:43:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c08Mx-0001T8-Ta for emacs-devel@gnu.org; Fri, 28 Oct 2016 10:42:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c08Mt-0006ea-T2 for emacs-devel@gnu.org; Fri, 28 Oct 2016 10:42:55 -0400 Original-Received: from chomsky.autogeree.net ([91.216.110.36]:60098) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c08Mt-0006eD-ME for emacs-devel@gnu.org; Fri, 28 Oct 2016 10:42:51 -0400 Original-Received: from ritchie.wxcvbn.org (localhost [127.0.0.1]) by wxcvbn.org (8.15.2/8.15.2) with ESMTP id u9SEfR19075001; Fri, 28 Oct 2016 16:41:27 +0200 (CEST) Original-Received: (from jca@localhost) by ritchie.wxcvbn.org (8.15.2/8.15.2/Submit) id u9SEfQ34003446; Fri, 28 Oct 2016 16:41:26 +0200 (CEST) Mail-Followup-To: Stefan Monnier , emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Fri, 28 Oct 2016 09:03:00 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 91.216.110.36 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:208947 Archived-At: Stefan Monnier writes: >> I wouldn't have thought that PROT_NONE vs PROT_READ|PROT_WRITE would >> have changed anything here, but on *some* OSes it does, however it is >> not portable. At least OpenBSD doesn't behave like what you describe. > > Are you sure? Can you point to concrete evidence? Erm, I think there was a problem with my tests. data: - system has 8GB of ram - no swap - "data" rlimit set to 32GB, the per-process maximum supported on OpenBSD/amd64 with Daniel's test program asking for 20GB: - mmap(PROT_NONE) _succeeds_ - mprotect(PROT_READ|PROT_WRITE) _succeeds_ An mmap call directly asking for 20GB with PROT_READ|PROT_WRITE also succeeds. The protection flags aren't checked to decide whether ENOMEM should be returned, and the process has no easy way to tell whether the requested amount of memory is actually usable (-> SIGBUS if the system can't map enough pages). The reason why my test initially failed is that I assumed that ulimit -d was 4GB on this box, not 1.5GB (default for OpenBSD/amd64). Not double-checking this was sloppy, my sincere apologies to Daniel and the other readers. > Not that's it's important (using a hard-coded number like 2GB wouldn't > work, so we'd more likely use something like w32heap.c's "pre-allocate > double the size", which doesn't suffer from that problem anyway and > still guarantees efficient behavior when growing a buffer progressively > from 1B to 100GB). Ack. Note that the test above was using the maximum value for ulimit -d; for the record, a single allocation of 2GB would be rejected by default on all of our supported platforms. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE