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: Tue, 29 Nov 2016 11:12:57 -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> <834m2qrux9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480446822 5897 195.159.176.226 (29 Nov 2016 19:13:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 19:13:42 +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 Tue Nov 29 20:13:38 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 1cBnqS-0000YL-J4 for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 20:13:37 +0100 Original-Received: from localhost ([::1]:38887 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnqW-0008Nr-1y for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 14:13:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnpy-0008Na-2j for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:13:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBnpx-00044j-1z for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:13:06 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54644) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBnpw-00044I-Od; Tue, 29 Nov 2016 14:13:04 -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=1FQfMmMbrlDkfEl0waXt7geq+Ajylnqhh2FhI7arxKo=; b=SCKRGngHo8pi/3k62YH0Gb4AGXHG9TlDSJB84eyJOcHR6X2g9YEkXHPP4FT2miqAnb3Etibu/HE4+2ltwJw5b1XUXeYPT8BoPIVIdTu5uQdCvIZmNZBajIbAFik8lkVbWiXW+JHD40eIXFH8+vYPe0XwdbXZgIOa0eyGMfUIC/aoeRunPP5AYxSoBCFxaeIb5QfrNP1lwodp8fKyJ4AKSpXSYe577EnhUNgQa1BOlgUN8T8uXrOYoT8efKYM4msgUMTkRYJyadgNJVJRAMZml5kWEZnSDogDSGSxwR3/GkbuEOULkLw3sX0JZsnlKhh/3uy3+74pKGWycEsQB960RQ==; Original-Received: from [2620:0:1008:1101:a803:88c3:331:8b1] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cBnpv-0003Oz-Eh; Tue, 29 Nov 2016 11:13:03 -0800 In-Reply-To: <834m2qrux9.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 Nov 2016 20:40:50 +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:209755 Archived-At: On Tue, Nov 29 2016, Eli Zaretskii wrote: >> From: John Wiegley >> Cc: eggert@cs.ucla.edu, dancol@dancol.org, emacs-devel@gnu.org >> Date: Mon, 28 Nov 2016 14:18:58 -0800 >> >> > 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 [...] >> >> If I didn't know you were talking about pdumper vs. unexec here, I'd swear >> this above paragraph was expressing my own concerns about merging Tromey's >> concurrency branch. > > Superficially, perhaps. But as soon as you look at the details, there > are two important differences. > > First, the only piece of code in the concurrency patch that is not > entirely trivial is a 60-line function (30% of whose line count is > comments and ifdef's). You're the only person I've ever seen use words like "entirely trivial" to describe the addition of shared-memory concurrency to a legacy single-threaded system. Even if the code for the threads system looks simple, the concepts involved are anything but. By contrast, the portable dumper is about marshalling, which I think is comparatively simpler. > That's all there is to understand there. The > rest is extremely simple, almost trivial: functions that directly map > into the corresponding system threads APIs, or 2-liners for creation, > checking, and otherwise simple management of the few new object types. > By contrast, the proposed patch, even in its initial version, weighs > in at 3200 lines in its core part, and almost none of it is trivial or > simple. > > What's more, it comes with the need to make important and non-trivial > decisions wrt which objects and data structures need to be dumped, and > how, something that requires intimate knowledge of the internals and > their use patterns, both at dump time and in interactive sessions. > These decisions will need to be revisited when the related objects are > added or modified, which is the part that averts me the most, because > it means extending the Lisp interpreter, which is already not easy, > will have become even harder. I don't see it as a problem that the internals of Emacs need to have knowledge of the internals of Emacs. What matters is whether adding new object types, which is already a very rare exercise, is made prohibitively hard. Keep in mind that any programmer who adds a new object type needs to *also* update the garbage collector, and GC and the portable dumper require exactly the same kind of object description. (I looked into actually unifying the GC and pdumper, but I don't think it's possible without introducing significant new abstractions. It's not worth it for something that happens so rarely as modification to core Emacs data type representations.) If you want to follow this reasoning to its logical conclusion, we should switch to Boehm GC. > The other important difference is that threads are an opt-in feature: > if you don't start any threads, Emacs with threads still works as it > did before, and you can just ignore anything related to threads. IOW, > threads are a feature we offer to Lisp programs that want to use it. > By contrast, dumping code is a central and mandatory part of building > Emacs and of its startup process. It cannot be ignored or made > optional. The portable dumper is also optional: you can always use the legacy unexec code, which isn't going away, or just rely on loadup (and the hypothetical ultra-fast lread we've discussed).