Re: Removal of unexec support from glibc malloc

[Paul Eggert <eggert at cs dot ucla dot edu>]

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.