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: Preview: portable dumper Date: Mon, 28 Nov 2016 23:14:32 +0200 Message-ID: <83twarxq6f.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <721b8fb1-5672-778e-b68f-a68b53308f55@cs.ucla.edu> <83vav7xs1p.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480367735 29277 195.159.176.226 (28 Nov 2016 21:15:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 21:15:35 +0000 (UTC) Cc: eggert@cs.ucla.edu, dancol@dancol.org, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 22:15:31 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 1cBTGs-0007Bv-DT for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 22:15:30 +0100 Original-Received: from localhost ([::1]:33060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBTGw-0006pS-1Y for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 16:15:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBTG2-0006nw-2v for emacs-devel@gnu.org; Mon, 28 Nov 2016 16:14:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBTFx-0008Ho-OY for emacs-devel@gnu.org; Mon, 28 Nov 2016 16:14:38 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBTFx-0008Hk-Ky; Mon, 28 Nov 2016 16:14:33 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3839 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cBTFw-0000Za-Qv; Mon, 28 Nov 2016 16:14:33 -0500 In-reply-to: (message from John Wiegley on Mon, 28 Nov 2016 12:47:10 -0800) 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:209700 Archived-At: > From: John Wiegley > Cc: Paul Eggert , dancol@dancol.org, emacs-devel@gnu.org > Date: Mon, 28 Nov 2016 12:47:10 -0800 > > >>>>> "EZ" == Eli Zaretskii writes: > > EZ> I'm not going to argue. If enough people think I'm mistaken and want to go > EZ> the portable dumper way, I will resign right here and now. It is very easy > EZ> to convince me to step down, because I hesitated to take this job to begin > EZ> with. > > EZ> Your call, crowd. > > OK, please let's take a few steps back and not make any rash decisions > today. :) It's no longer my decision. > If Daniel's proposing an internal optimization and is willing to maintain it > -- and if it doesn't make work for other contributors -- I suggest we accept > it as long as he, or someone else, is willing to support it. Emacs future cannot depend on a single person. We had more than once a situation where key developer(s) left leaving a feature or a whole area unmaintained. If some development isn't a one-time job -- and this one surely isn't -- then experience shows that any arcane code in C that loses its experts will become unmaintained and unmaintainable. The only hope for us to escape this fate is to do it in a way that most contemporary contributors understand and can easily learn to hack, which means do it mostly in Lisp, reusing the existing C machinery that is proven by time and doesn't need maintenance -- 'load' and its cousins. That was what I proposed. The advantage of that is that Emacs then becomes a normal program, one that doesn't dump itself in any way, shape, or form, but instead reads in a byte-compiled file, using the normal memory allocation routines. No more need to save any internal state, worry about relocations, ASLR, etc. It amazes me that the advantages of that are not immediately clear to everyone, but I guess I'm biased. > At the very least, it frees us from dependence on a glibc feature > that is doomed to disappear. No one is suggesting to stay with unexec. The disagreement is about where to go to get rid of it. > If later the work becomes difficult to support, or if Daniel disappears, won't > we just be returning to the same position as now? If that happeans, we can > take what we've learned and try another approach, such as speeding up .elc > loading. Or, if someone comes up with a better alternative in the meantime, we > can just switch to it. I don't think this is practical. We cannot go back, certainly not when unexec requires the expertise it does. No one will agree to go back. Like with unexec, the only way the portable dumper will be thrown away is if/when it turns out it is an obstacle to Emacs development, by which time it will be too late. > Accepting this patch doesn't mean we don't try the .elc speedup idea. The only > thing we have to make sure is that it doesn't unduly increase the difficulty > of adding new Lisp objects. Accepting this patch means we believe in this direction, consider it a perspective one, enough so that we are willing to invest a non-trivial amount of energy into making it happen, fix the fallout, debug the results, etc. We are talking about at least one major release, maybe more, and definitely several minor releases. IOW, we are talking several years. I don't think we should gamble with such high stakes, not unless we sure we want to go there, because this is the best alternative of ditching unexec. Anyway, I already wrote all this; there was a long discussion about these issues, it's in the archives. I have nothing else to add to what I wrote back then. This project needs to decide where it wants to go, and the rest will be history.