From owner-freebsd-hackers@freebsd.org Fri Nov 18 22:22:10 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36113C48755 for ; Fri, 18 Nov 2016 22:22:10 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1463519C0; Fri, 18 Nov 2016 22:22:09 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D3F5916006F; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4Uy_Ra3XdPtE; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 15A7F160070; Fri, 18 Nov 2016 14:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rz5yrrQtfNxQ; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Received: from [192.168.1.9] (unknown [47.153.178.162]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E296B16006F; Fri, 18 Nov 2016 14:22:07 -0800 (PST) Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture To: Ed Maste References: <82a03552-8f33-2dbe-6bb5-54f649b29db7@cs.ucla.edu> <86vavxs2cn.fsf@members.fsf.org> <5adee8d9-8f08-9536-a95f-ae64719d6a0f@cs.ucla.edu> <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> Cc: Ashish SHUKLA , freebsd-hackers@freebsd.org, 24892@debbugs.gnu.org, Brooks Davis From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <1dc6fa8c-7378-6e4e-1d9e-86c962fc48bb@cs.ucla.edu> Date: Fri, 18 Nov 2016 14:22:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 Nov 2016 22:56:31 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 22:22:10 -0000 Ed Maste wrote: > arm64 support was first available in a release in FreeBSD 11.0, without= sbrk, and sbrk never existed on the stable/11 branch. Thanks, I didn't know that. So Emacs has never worked in this environment= . > it seems there's an implementation that allocates memory out of a large= array in .bss used for some platforms - could we make use of that here? Quite possibly. Unfortunately the code that uses that array (in gmalloc.c= ) also=20 uses sbrk to move the break past the end of the large array. The large ar= ray is=20 intended for use only during the build process; during ordinary execution= , sbrk=20 is used. Perhaps Emacs could work around the problem by supplying a user-space sbr= k=20 emulator, which uses mmap to support the old-fashioned model where the he= ap is=20 contiguous. Is that something that could be done easily? That is, is ther= e some=20 way to reserve the address space for a potentially-large Emacs heap right= after=20 .bss, such that library calls to malloc and mmap won't use this address s= pace?=20 That might do the trick. Brooks Davis wrote: > What does emacs actually need from sbrk()? Could it get by with someth= ing with the same interface allocating from .bss or does it need its allo= cations to be at the end of .bss? I think more the latter. The problem with a fixed-size .bss is that whate= ver=20 size we pick during the build is likely to be wrong for users. Also, Emac= s saves=20 the entire build-time .bss into an executable, so an enormous .bss will b= e=20 counterproductive.