GNU bug report logs - #23529
Request for fixing randomize_va_space build issues

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philippe Vaucher <philippe.vaucher <at> gmail.com>
Cc: p.stephani2 <at> gmail.com, eggert <at> cs.ucla.edu, 23529 <at> debbugs.gnu.org
Subject: bug#23529: Request for fixing randomize_va_space build issues
Date: Tue, 13 Sep 2016 17:47:18 +0300

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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.