[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removal of unexec support from glibc malloc

From: Paul Eggert
Subject: Re: Removal of unexec support from glibc malloc
Date: Mon, 18 Jan 2016 11:50:31 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]