Re: Removal of unexec support from glibc malloc

[Ali Bahrami]

On 1/18/16 12:20 PM, John Wiegley wrote:
> > > > > > Florian Weimer <address@hidden> writes:
>
> > This is a heads-up that glibc malloc will likely remove support code for the
> > Emacs unexec mechanism during the coming year.
>
> Hi Florian,
>
> I think you might understand our dismay at hearing this without any prior
> notice, since Emacs does depend on the unexec mechanism, and we are currently
> preparing a major upcoming release (25.1) that makes use of it.
>
> Could we start a discussion on whether it's possible to still allow this
> support in some form? You are asking us to make a rather significant change to
> low-level code that has been functioning for a very long time. I'm not even
> sure yet what lack of this support entails for existing and future Emacsen.
>
> As we are both projects under the GNU banner, I hope we can find a middle
> ground to further the GNU project, yet without such sudden and unexpected
> costs. At the very least, allowing a longer timeline before removing unexec
> functionality will permit us to research, prepare, and possibly suggest
> counter-proposals to achieve the same overall objective.

Hi Everyone,

   I'm a long time lurker here. I've been using GNU Emacs since the
early releases in the 80's, first on Sun3 workstations, and later on
many systems, including Sun and GNU/Linux. I'm also one of the 2 folks
at what used to be Sun, who work on the Solaris linkers. And, I'm
nominally the contact point for emacs on Solaris:

    
https://java.net/projects/solaris-userland/sources/gate/show/components/emacs?rev=5252

This thread therefore intersects a number of my interests, and I'd
like to throw in my 2 cents...

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.

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.

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.

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.

Thanks...

- Ali