This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fwd: glibc and unexec
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Joseph Myers <joseph at codesourcery dot com>, Mark Brown <ms_brown at sbcglobal dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 18 Jan 2016 18:41:42 -0800
- Subject: Re: Fwd: glibc and unexec
- Authentication-results: sourceware.org; auth=none
- References: <E1aLIs3-00021d-VR at fencepost dot gnu dot org> <569D7328 dot 5030502 at sbcglobal dot net> <alpine dot DEB dot 2 dot 10 dot 1601182327430 dot 18513 at digraph dot polyomino dot org dot uk>
"Emacs by itself should not inhibit glibc from
making significant malloc performance improvements that would benefit a
large set of programs". See
<https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00542.html>.
Yes, I still think that's the bottom line here. Florian's more-recent messages
suggest that the "removal of unexec support" thread is to some extent a false
alarm, in that current Emacs executables will still run with new glibc, and
current Emacs sources will still configure and run with new glibc. It's true
that there will be a performance hit in the latter case, but 15% CPU performance
hits (on specially-constructed benchmarks designed to measure the problem) are
acceptable while we work on a better solution in Emacs.
We need to confirm this. But even if it's not confirmed and Emacs's own malloc
implementation does not work with new glibc, we should be able to fix things on
the Emacs side; perhaps not in the next release (Emacs 25), but soon enough.
This is just my opinion, and John Wiegley (the current Emacs maintainer) would
need to agree. But it appears that he would like to head in this direction too; see:
https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01024.html