This is the mail archive of the
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Emacs Development <Emacs-devel at gnu dot org>
- Date: Mon, 18 Jan 2016 11:50:31 -0800
- Subject: Re: Removal of unexec support from glibc malloc
- Authentication-results: sourceware.org; auth=none
- References: <569CDB81 dot 6040600 at redhat dot com> <569D3BE0 dot 6050103 at cs dot ucla dot edu> <m2a8o2vg5x dot fsf at newartisans dot com>
John Wiegley wrote:
Can you elaborate what unexec has been doing for us up till now, and what
living without it will entail in terms of both technical content and work
unexec lets Emacs save much of its internal state into an executable that will
start more quickly than an Emacs that needs to regenerate that internal state
from source files. Originally, unexec also made the internal-state read-only,
which helped performance significantly long ago; nowadays the performance is no
longer worth the porting hassle so Emacs no longer does that.
Emacs's internal state includes the heap controlled by malloc, as Emacs calls
malloc before unexec, and the restarted executable also invokes malloc. Hence
Emacs unexec must take care that the restarted executable's malloc doesn't get
confused by the ELF munging that unexec does when writing out Emacs's internal
state. It does this in part by calling malloc_get_state just before unexec, and
having the restarted executable call malloc_set_state during startup (even
before 'main' is called). This is done via __malloc_initialize_hook, and I
expect this is the sort of thing that Florian is talking about when he says the
glibc API is changing.
Emacs could live without the current unexec in a semi-portable way by doing what
XEmacs does, which is to write out data and mmap it in later (sorry, don't know
the details). There are other possibilities, e.g., have unexec write out the
state in the form of C files that are compiled and linked in the usual way to
build a faster-starting executable (this would be an Emacs API change, though).
Any such changes would take some time to hack into something reliable and
portable, and so will have to wait until after Emacs 25 is out.