Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Ali Bahrami <address@hidden>
> Date: Mon, 18 Jan 2016 15:45:50 -0700
> 
> Emacs unexec was pretty cool and amazing stuff when I first encountered
> it back in the day, and lots of people have worked to keep it working,
> as operating system environments became more complicated. Sun added the
> dldump() function in the mid-90's just to support emacs. Even today,
> unexec is still a pretty cute trick.
> 
> I have to say that it's not worth doing anymore. Today's slowest machines
> are pure science fiction in their speed and abilities compared to the 80's.
> Although emacs has grown too, it's on a completely different scale. Has it
> grown 10x? Perhaps, but that's nothing, relative to the hardware. I'm also
> reminded of when we got our first risc machines in the 90's. Some of them
> didn't have unexec working, and we'd just use temacs instead. It took on
> the order of 5-10 seconds to start up and become useful, rather than
> starting instantaneously. That was nearly 20 years ago.

It still takes on the order of 5 sec, even though the machines are
much faster.  See the timings published by someone else in this thread
(which I believe were for an optimized build; I see about twice that
here with an unoptimized one).  I think on some systems, like OS X, it
will be much longer, because they have some large and complex files
preloaded.  Many people consider a 5-sec delay a non-starter, so I
think using temacs and loading all the necessary stuff at startup is
not an acceptable option, except on systems that have no other choice,
if there are still such systems we support.

> Unexec is complicated, and it is a problem for alternative non-brk
> based mallocs, or ASLR. One of the strong design points of emacs is
> its use of a minimal and simple C core, with the system largely written
> in lisp. Losing unexec would leave an even simpler core.

We are not wedded to unexec in any kind, including the Catholic kind.
It is here because (a) it "just works" and breaks only very rarely,
and, most importantly, (b) no one has stepped forward with code to
replace it on a VCS branch where one could checkout the results and
see how clean the code is how well it works in practice.

> Before you fight to to save unexec, I'd encourage you to measure the
> impact, and see if it still matters. If it does, then it would be
> worthwhile to consider other means for getting those bytes into
> memory quickly that don't involve second guessing object layout,
> memory allocation, and process layout. Speaking as a linker guy,
> linking is only going to get more dynamic, and more complex, going
> forward. You might be glad, down the road, to be out of that game.

Once again, there are no objections to replacing unexec with something
else, not in principle.  You are mistaken if you think this is the
core of the issue.

> That's not to say that John's concerns above aren't reasonable.
> This is big enough that you don't want to force it, but perhaps
> it's time to start considering alternatives.

Considering alternatives is not what will make this done.  The only
way anything of this significance gets done in Emacs is for Someone™
to present working code that can be a drop-in replacement for what we
do today.  No one has done that till now.  That's the only thing that
stands between some real progress in this matter and just another
longish discussion that ends up collecting dust in the archives (sorry
for being blunt and a tad cynical).