From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23529: Request for fixing randomize_va_space build issues Date: Tue, 13 Sep 2016 17:47:18 +0300 Message-ID: <83intz97rd.fsf@gnu.org> References: <02c57124-ef39-bc30-89ba-998986d070fc@cs.ucla.edu> <834m5tapuu.fsf@gnu.org> <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473778102 21750 195.159.176.226 (13 Sep 2016 14:48:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Sep 2016 14:48:22 +0000 (UTC) Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org To: Philippe Vaucher Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 13 16:48:16 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1bjp0Q-0004fA-Gq for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Sep 2016 16:48:14 +0200 Original-Received: from localhost ([::1]:49390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjp0O-00040y-Kk for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Sep 2016 10:48:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjp0I-0003zz-IV for bug-gnu-emacs@gnu.org; Tue, 13 Sep 2016 10:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjp0E-0004A5-E3 for bug-gnu-emacs@gnu.org; Tue, 13 Sep 2016 10:48:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:32869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjp0E-00049m-AX for bug-gnu-emacs@gnu.org; Tue, 13 Sep 2016 10:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bjp0E-0003Gx-2q for bug-gnu-emacs@gnu.org; Tue, 13 Sep 2016 10:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Sep 2016 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147377805412546 (code B ref 23529); Tue, 13 Sep 2016 14:48:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 13 Sep 2016 14:47:34 +0000 Original-Received: from localhost ([127.0.0.1]:58814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjozh-0003GA-TS for submit@debbugs.gnu.org; Tue, 13 Sep 2016 10:47:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjozc-0003Fq-68 for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 10:47:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjozS-0002sB-K6 for 23529@debbugs.gnu.org; Tue, 13 Sep 2016 10:47:18 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjozS-0002rq-Fz; Tue, 13 Sep 2016 10:47:14 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2562 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjozR-0003Jb-HE; Tue, 13 Sep 2016 10:47:13 -0400 In-reply-to: (message from Philippe Vaucher on Mon, 12 Sep 2016 16:18:11 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123258 Archived-At: What about this idea: https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01049.html To recap: the idea is to dump the dumping (pun intended), and instead load the preloaded packages upon each session start. This currently takes about 5 to 12 sec, depending on the platform and the optimization switches, but a simple optimization brings it down to below 0.5 sec in an optimized build. Further testing indicates that lumping all of the files we preload into a single .elc file reduces the load time even more, so it becomes around 0.1-0.2 sec. That should be short enough to make it negligible, right? This sounds as a much easier and low-risk approach. Its significant advantage is that it doesn't require any serious changes in the low-level infrastructure -- no need for generating C code or dump data records as part of DEFUN, defsubr, and staticpro, no need to hunt for, dump, and restore global variables that hold Lisp objects, no dependencies on external tools, etc. Almost everything in support of this method, like the ability to redirect results of compiling several source files into a single .elc file, can be done in Lisp, mainly in loadup.el, plus some Makefile changes in the last stages of the build process. A much simpler design and higher-level implementation mean more people could be involved in working on this, testing, and debugging, instead of relying on a couple of "usual suspects" who are overloaded anyway. Having a single .elc file provides a nice bonus of being able to run Emacs even if the Lisp files are not available. And re-dumping can be supported with almost no effort. If this idea is accepted, the first question to ask is whether we still need pure storage on modern platforms. If we do, find_string_data_in_pure will have to be sped up by using a hash table or some such. If pure storage is not needed, purecopy can be a no-op and find_string_data_in_pure should simply go away, which is of course much easier. Comments?