From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ali Bahrami Newsgroups: gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Mon, 18 Jan 2016 15:45:50 -0700 Message-ID: <569D6B1E.6020002@emvision.com> References: <569CDB81.6040600@redhat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453159209 11679 80.91.229.3 (18 Jan 2016 23:20:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 23:20:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 19 00:20:00 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aLJ5a-00063z-L2 for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 00:19:59 +0100 Original-Received: from localhost ([::1]:34177 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLJ5Z-0003a3-Id for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 18:19:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLJ5L-0003Zx-QL for emacs-devel@gnu.org; Mon, 18 Jan 2016 18:19:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLJ5H-0003bE-Nk for emacs-devel@gnu.org; Mon, 18 Jan 2016 18:19:43 -0500 Original-Received: from gateway.emvision.com ([71.33.253.1]:17958 helo=emvision.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLJ5H-0003as-8a for emacs-devel@gnu.org; Mon, 18 Jan 2016 18:19:39 -0500 Original-Received: from bullwinkle.emvision.com (pod.emvision.com [198.182.198.2]) by emvision.com (8.13.6/8.13.6) with ESMTP id u0IMjp4M026301 for ; Mon, 18 Jan 2016 15:45:52 -0700 (MST) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (emvision.com [198.182.198.5]); Mon, 18 Jan 2016 15:45:52 -0700 (MST) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 71.33.253.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198315 Archived-At: On 1/18/16 12:20 PM, John Wiegley wrote: >>>>>> Florian Weimer writes: > >> This is a heads-up that glibc malloc will likely remove support code for the >> Emacs unexec mechanism during the coming year. > > Hi Florian, > > I think you might understand our dismay at hearing this without any prior > notice, since Emacs does depend on the unexec mechanism, and we are currently > preparing a major upcoming release (25.1) that makes use of it. > > Could we start a discussion on whether it's possible to still allow this > support in some form? You are asking us to make a rather significant change to > low-level code that has been functioning for a very long time. I'm not even > sure yet what lack of this support entails for existing and future Emacsen. > > As we are both projects under the GNU banner, I hope we can find a middle > ground to further the GNU project, yet without such sudden and unexpected > costs. At the very least, allowing a longer timeline before removing unexec > functionality will permit us to research, prepare, and possibly suggest > counter-proposals to achieve the same overall objective. > Hi Everyone, I'm a long time lurker here. I've been using GNU Emacs since the early releases in the 80's, first on Sun3 workstations, and later on many systems, including Sun and GNU/Linux. I'm also one of the 2 folks at what used to be Sun, who work on the Solaris linkers. And, I'm nominally the contact point for emacs on Solaris: https://java.net/projects/solaris-userland/sources/gate/show/components/emacs?rev=5252 This thread therefore intersects a number of my interests, and I'd like to throw in my 2 cents... Emacs unexec was pretty cool and amazing stuff when I first encountered it back in the day, and lots of people have worked to keep it working, as operating system environments became more complicated. Sun added the dldump() function in the mid-90's just to support emacs. Even today, unexec is still a pretty cute trick. I have to say that it's not worth doing anymore. Today's slowest machines are pure science fiction in their speed and abilities compared to the 80's. Although emacs has grown too, it's on a completely different scale. Has it grown 10x? Perhaps, but that's nothing, relative to the hardware. I'm also reminded of when we got our first risc machines in the 90's. Some of them didn't have unexec working, and we'd just use temacs instead. It took on the order of 5-10 seconds to start up and become useful, rather than starting instantaneously. That was nearly 20 years ago. Unexec is complicated, and it is a problem for alternative non-brk based mallocs, or ASLR. One of the strong design points of emacs is its use of a minimal and simple C core, with the system largely written in lisp. Losing unexec would leave an even simpler core. Before you fight to to save unexec, I'd encourage you to measure the impact, and see if it still matters. If it does, then it would be worthwhile to consider other means for getting those bytes into memory quickly that don't involve second guessing object layout, memory allocation, and process layout. Speaking as a linker guy, linking is only going to get more dynamic, and more complex, going forward. You might be glad, down the road, to be out of that game. That's not to say that John's concerns above aren't reasonable. This is big enough that you don't want to force it, but perhaps it's time to start considering alternatives. Thanks... - Ali