From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Mon, 28 Nov 2016 13:55:52 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <721b8fb1-5672-778e-b68f-a68b53308f55@cs.ucla.edu> <83vav7xs1p.fsf@gnu.org> <83twarxq6f.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480370206 30821 195.159.176.226 (28 Nov 2016 21:56:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 21:56:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: John Wiegley , eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 22:56:41 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 1cBTug-0006tA-O4 for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 22:56:39 +0100 Original-Received: from localhost ([::1]:33291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBTuk-0005Uq-JD for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 16:56:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBTu8-0005UY-0x for emacs-devel@gnu.org; Mon, 28 Nov 2016 16:56:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBTu6-0005il-Ki for emacs-devel@gnu.org; Mon, 28 Nov 2016 16:56:04 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38890) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBTu6-0005iB-72; Mon, 28 Nov 2016 16:56:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=48zooh+tvH6fShfKttW9+AjYN7jeVQUR/Bco9IGpD1E=; b=fsrHsWmgI1YMAo6Jdsh4ZlT9JjdU6mHtSqH0bkdTcrSZDd7yCBz9e2j0C7PqtjHRbBkzlKlnWtrTflPylV/2Cg7CN/E2bIBYxZWhEd1KrPtaWsvls+3TbzIzfGJzgDyzl6w7M1iE0r65IlML0864bHUNHjkAOyc4Hoc/N21KzKvqkslgxBvAByAlkM98KG/zSZmDOcps2LYTVVtxIacFMNXELZ47MnHOZ8Tye9uDBepmRwCSCqX4uy30RbTnsBo3IjpmvOUUpw+AI1VzlfjZnEfoOaKLmKRQJk0Qq2Qq1MQFCcAdwmgxSsw2Q7Jcp1O7SnfJ1cIVX86n8SDs0g0b6A==; Original-Received: from [2620:0:1008:100b:fd76:a51f:62d3:e4cc] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cBTu4-0000gu-2s; Mon, 28 Nov 2016 13:56:00 -0800 In-Reply-To: <83twarxq6f.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Nov 2016 23:14:32 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209703 Archived-At: On Mon, Nov 28 2016, Eli Zaretskii wrote: >> 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 are a long way away from the day when only one person left on earth can simultaneously hold in his mind the concepts of addition, modulus, and binary search in C. The operating principle of this work is very simple. If we need internals documentation, I'll write documentation --- but there's really not much to it. > 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. They don't need maintenance --- except that they're at least an order of magnitude too slow right now, and nobody's stepped up to do the maintenance work necessary to make them useful in a new use case. > 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. The whole point of the portable dumper is that you don't need to worry about ASLR, ASAN, TSAN, or whatever libc people dream up next. Emacs *is* a normal program --- it does only the things normal programs are allowed to do and that platforms support, things like pointer assignment and reading from a file. A "relocation" is literally just addition --- it's not some horrible dynamic programming monstrosity like redisplay, which I understand used to literally have a skull and crossbones in ASCII art over the main body of the code. Using your arguments, we should switch to Pango for text layout, FUSE for remote access, clang-format for indentation, and --- hell, let's just make Emacs a webapp. If you want maximum technological democratization, you want JavaScript. See https://atom.io/. >> 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. Unexec will keep working as well as it does today. >> 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. The stakes aren't high. As johnw wrote, unexec will keep working as well as it does today, and nobody is stopping anyone else making