Removal of unexec support from glibc malloc
Paul Eggert
eggert@cs.ucla.edu
Mon Jan 18 19:50:00 GMT 2016
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
> required?
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.
More information about the Libc-alpha
mailing list