From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Tue, 19 Jan 2016 17:58:33 +0200 Message-ID: <837fj5d0ie.fsf@gnu.org> References: <569CDB81.6040600@redhat.com> <569D6B1E.6020002@emvision.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1453219125 24489 80.91.229.3 (19 Jan 2016 15:58:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 15:58:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ali Bahrami Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 19 16:58:45 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 1aLYg8-0002dD-JY for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 16:58:44 +0100 Original-Received: from localhost ([::1]:37674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLYg8-0002Z4-28 for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 10:58:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLYft-0002Yj-VO for emacs-devel@gnu.org; Tue, 19 Jan 2016 10:58:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLYfo-0005E4-T0 for emacs-devel@gnu.org; Tue, 19 Jan 2016 10:58:29 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLYfo-0005Dz-Q4; Tue, 19 Jan 2016 10:58:24 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2060 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLYfo-0007NI-6c; Tue, 19 Jan 2016 10:58:24 -0500 In-reply-to: <569D6B1E.6020002@emvision.com> (message from Ali Bahrami on Mon, 18 Jan 2016 15:45:50 -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.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:198362 Archived-At: > From: Ali Bahrami > Date: Mon, 18 Jan 2016 15:45:50 -0700 > > 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. It still takes on the order of 5 sec, even though the machines are much faster. See the timings published by someone else in this thread (which I believe were for an optimized build; I see about twice that here with an unoptimized one). I think on some systems, like OS X, it will be much longer, because they have some large and complex files preloaded. Many people consider a 5-sec delay a non-starter, so I think using temacs and loading all the necessary stuff at startup is not an acceptable option, except on systems that have no other choice, if there are still such systems we support. > 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. We are not wedded to unexec in any kind, including the Catholic kind. It is here because (a) it "just works" and breaks only very rarely, and, most importantly, (b) no one has stepped forward with code to replace it on a VCS branch where one could checkout the results and see how clean the code is how well it works in practice. > 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. Once again, there are no objections to replacing unexec with something else, not in principle. You are mistaken if you think this is the core of the issue. > 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. Considering alternatives is not what will make this done. The only way anything of this significance gets done in Emacs is for Someone™ to present working code that can be a drop-in replacement for what we do today. No one has done that till now. That's the only thing that stands between some real progress in this matter and just another longish discussion that ends up collecting dust in the archives (sorry for being blunt and a tad cynical).