Removal of unexec support from glibc malloc

Removal of unexec support from glibc malloc

[Florian Weimer]

Hi,

this is a heads-up that glibc malloc will likely remove support code for
the Emacs unexec mechanism during the coming year.  The reason is that
we want to be able to change heap layout between glibc releases, for
standards conformance, performance and security improvements:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=19473>

This only affects the glibc API, so Emacs is unlikely to compile from
source until you remove the undump mechanism.  We will work very hard to
keep existing Emacs binaries working, but we might miss some corner
cases initially.  Those will be treated as bugs and fixed (although this
causes a significant ongoing maintenance overhead for glibc upstream,
basically maintaining a separate malloc implementation indefinitely).

Florian

Re: Removal of unexec support from glibc malloc

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

>>>>> Florian Weimer <fweimer@redhat.com> 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.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Removal of unexec support from glibc malloc

[Paul Eggert]

Florian Weimer wrote:
> this is a heads-up that glibc malloc will likely remove support code for
> the Emacs unexec mechanism during the coming year.

Thanks for that heads-up. Making the Emacs unexec mechanism more portable has 
been our to-do list for some time, and this will light more of a fire under it. 
We're already under a feature freeze for Emacs 25, though, so Emacs 25 will have 
to go out without the fix (which will be reasonably substantial, alas).

> This only affects the glibc API, so Emacs is unlikely to compile from
> source until you remove the undump mechanism.

Emacs should still build and run even if the glibc API is changed, as Emacs 
./configure probes for the glibc malloc-related API and falls back on its own 
malloc implementation otherwise. If some glitch prevents this from working with 
the new glibc API, I'd like to get this fixed before Emacs 25 comes out, so that 
Emacs 25 will build and run with newer glibc.

Can you explain the problem in more detail? What are the symptoms if you do the 
following with the next-generation glibc API?

git clone --branch emacs-25 git://git.savannah.gnu.org/emacs.git
cd emacs
./autogen.sh
./configure
make

Is there some way that Emacs developers (who are typically not glibc experts) 
can easily test with the next-generation glibc API?

Re: Removal of unexec support from glibc malloc

[John Wiegley]

>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:

> Thanks for that heads-up. Making the Emacs unexec mechanism more portable
> has been our to-do list for some time, and this will light more of a fire
> under it. We're already under a feature freeze for Emacs 25, though, so
> Emacs 25 will have to go out without the fix (which will be reasonably
> substantial, alas).

Hi Paul,

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?

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Removal of unexec support from glibc malloc

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On 01/18/2016 11:30 AM, John Wiegley wrote:
>>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
>> Thanks for that heads-up. Making the Emacs unexec mechanism more portable
>> has been our to-do list for some time, and this will light more of a fire
>> under it. We're already under a feature freeze for Emacs 25, though, so
>> Emacs 25 will have to go out without the fix (which will be reasonably
>> substantial, alas).
> 
> Hi Paul,
> 
> 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?

As long as the ABI support is there, we can keep using the "separate
malloc implementation" even if glibc doesn't cooperate by providing
convenient headers to access it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Removal of unexec support from glibc malloc

[Paul Eggert]

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.

Re: Removal of unexec support from glibc malloc

[Zack Weinberg]

On Mon, Jan 18, 2016 at 2:47 PM, Daniel Colascione <dancol@dancol.org> wrote:
>
> As long as the ABI support is there, we can keep using the "separate
> malloc implementation" even if glibc doesn't cooperate by providing
> convenient headers to access it.

Clarification: it will not be possible to link new executables against
the symbols in question. (This is what a "compat symbol" in glibc is -
available only to existing binaries, not to new invocations of ld.)

zw

Re: Removal of unexec support from glibc malloc

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On 01/18/2016 11:50 AM, Paul Eggert wrote:
> 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 does go to a lot of trouble to avoid taking COW faults on
purespace objects though.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Removal of unexec support from glibc malloc

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On 01/18/2016 11:54 AM, Zack Weinberg wrote:
> On Mon, Jan 18, 2016 at 2:47 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>
>> As long as the ABI support is there, we can keep using the "separate
>> malloc implementation" even if glibc doesn't cooperate by providing
>> convenient headers to access it.
> 
> Clarification: it will not be possible to link new executables against
> the symbols in question. (This is what a "compat symbol" in glibc is -
> available only to existing binaries, not to new invocations of ld.)

Oh, with a linker script or other hackery, I'm sure I could make it
available to new invocations of ld. It's just bytes.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 18 Jan 2016 11:50:31 -0800
> 
> 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.

There's also what the MS-Windows port does (temacs allocates off a
static array), which AFAIK is entirely portable, and doesn't require
mmap.  See w32heap.c.

Re: Removal of unexec support from glibc malloc

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On 01/18/2016 12:02 PM, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Mon, 18 Jan 2016 11:50:31 -0800
>>
>> 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.
> 
> There's also what the MS-Windows port does (temacs allocates off a
> static array), which AFAIK is entirely portable, and doesn't require
> mmap.  See w32heap.c.
> 

It's a portable stopgap, maybe, but a real portable dumper would be
_much_ better, since then Emacs could be a much safer
position-independnent executable (as a portable dumper would relocate
the dump as it loads, since it knows where all the pointers are).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Removal of unexec support from glibc malloc

[Wolfgang Jenkner]

On Mon, Jan 18 2016, Eli Zaretskii wrote:

> There's also what the MS-Windows port does (temacs allocates off a
> static array), which AFAIK is entirely portable, and doesn't require
> mmap.  See w32heap.c.

Isn't hybrid malloc the portable version of this?  A patch series for
this already exists (bug##22086), but Paul said that he wanted to get
rid of src/gmalloc.c even for allocations before dumping, IIUC.

Wolfgang

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/18/2016 08:20 PM, John Wiegley wrote:
>>>>>> Florian Weimer <fweimer@redhat.com> 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.

This is the prior notice.  I'm writing to you before the patch is even
written.  This is not something which is going to happen overnight.

> 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.

That's because others in the GNU ecosystem have bent over backwards to
support this mechanism, at a real cost to them.

I think it is time to tackle it at the root.  If you cannot make the
changes yourself, we'll have to make sure that you have a replacement
available when the need arises.  Even if we have to do the development,
it will pay off fairly soon on the toolchain side.

Florian

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  fweimer@redhat.com,  Emacs-devel@gnu.org
> Date: Mon, 18 Jan 2016 21:24:34 +0100
> 
> On Mon, Jan 18 2016, Eli Zaretskii wrote:
> 
> > There's also what the MS-Windows port does (temacs allocates off a
> > static array), which AFAIK is entirely portable, and doesn't require
> > mmap.  See w32heap.c.
> 
> Isn't hybrid malloc the portable version of this?

No, not AFAIU.

> A patch series for this already exists (bug##22086), but Paul said
> that he wanted to get rid of src/gmalloc.c even for allocations
> before dumping, IIUC.

The MS-Windows port doesn't use gmalloc.c.

Re: Removal of unexec support from glibc malloc

[Wolfgang Jenkner]

On Mon, Jan 18 2016, Eli Zaretskii wrote:

>> > There's also what the MS-Windows port does (temacs allocates off a
>> > static array), which AFAIK is entirely portable, and doesn't require
>> > mmap.  See w32heap.c.
>> 
>> Isn't hybrid malloc the portable version of this?
>
> No, not AFAIU.

I meant: Hybrid malloc uses src/sheap.c, which implements a static array
which is used for allocations before dumping.  And this is portable.

I didn't want to imply any genealogical relations between this and
w32heap.c.

Re: Removal of unexec support from glibc malloc

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

Daniel Colascione <dancol@dancol.org> schrieb am Mo., 18. Jan. 2016 um
21:05 Uhr:

> On 01/18/2016 12:02 PM, Eli Zaretskii wrote:
> >> From: Paul Eggert <eggert@cs.ucla.edu>
> >> Date: Mon, 18 Jan 2016 11:50:31 -0800
> >>
> >> 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.
> >
> > There's also what the MS-Windows port does (temacs allocates off a
> > static array), which AFAIK is entirely portable, and doesn't require
> > mmap.  See w32heap.c.
> >
>
> It's a portable stopgap, maybe, but a real portable dumper would be
> _much_ better, since then Emacs could be a much safer
> position-independnent executable (as a portable dumper would relocate
> the dump as it loads, since it knows where all the pointers are).
>
>
I completely agree. Also see the existing bugs
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20215 and
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20868.
Does anybody have a rough estimate what would be required to make the
dumper really portable?

[-- Attachment #2: Type: text/html, Size: 2125 bytes --]

Re: Removal of unexec support from glibc malloc

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]

On 01/18/2016 02:10 PM, Philipp Stephani wrote:
> 
> 
> Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>> schrieb
> am Mo., 18. Jan. 2016 um 21:05 Uhr:
> 
>     On 01/18/2016 12:02 PM, Eli Zaretskii wrote:
>     >> From: Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>>
>     >> Date: Mon, 18 Jan 2016 11:50:31 -0800
>     >>
>     >> 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.
>     >
>     > There's also what the MS-Windows port does (temacs allocates off a
>     > static array), which AFAIK is entirely portable, and doesn't require
>     > mmap.  See w32heap.c.
>     >
> 
>     It's a portable stopgap, maybe, but a real portable dumper would be
>     _much_ better, since then Emacs could be a much safer
>     position-independnent executable (as a portable dumper would relocate
>     the dump as it loads, since it knows where all the pointers are).
> 
> 
> I completely agree. Also see the existing bugs
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20215 and
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20868.
> Does anybody have a rough estimate what would be required to make the
> dumper really portable? 

I think it depends on how much we depend on non-lisp malloc-sourced
memory allocations. I honestly don't know.

As long as we're talking about work to do: I'd love for the new portable
dumper to support dumping Emacs multiple times. I've had to put a lot of
effort into my configuration to get Emacs to start in an acceptable
time, and a lot of people tolerate multi-second Emacs startup times.
It'd be nice if we could dump Emacs after loading user customizations.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Removal of unexec support from glibc malloc

[Joseph Myers]

On Mon, 18 Jan 2016, Daniel Colascione wrote:

> On 01/18/2016 11:54 AM, Zack Weinberg wrote:
> > On Mon, Jan 18, 2016 at 2:47 PM, Daniel Colascione <dancol@dancol.org> wrote:
> >>
> >> As long as the ABI support is there, we can keep using the "separate
> >> malloc implementation" even if glibc doesn't cooperate by providing
> >> convenient headers to access it.
> > 
> > Clarification: it will not be possible to link new executables against
> > the symbols in question. (This is what a "compat symbol" in glibc is -
> > available only to existing binaries, not to new invocations of ld.)
> 
> Oh, with a linker script or other hackery, I'm sure I could make it
> available to new invocations of ld. It's just bytes.

Being a compat symbol also means that future architecture ports and ABIs 
don't include the functionality at all.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Removal of unexec support from glibc malloc

[Óscar Fuentes]

Daniel Colascione <dancol@dancol.org> writes:

> As long as we're talking about work to do: I'd love for the new portable
> dumper to support dumping Emacs multiple times. I've had to put a lot of
> effort into my configuration to get Emacs to start in an acceptable
> time, and a lot of people tolerate multi-second Emacs startup times.
> It'd be nice if we could dump Emacs after loading user customizations.

This would turn `emacs -Q' into something meaningless, right?

What I would like from a new dumper is to be amenable to memory tools,
such as valgrind which, AFAIK, is unusable nowadays with a dumped emacs.

Re: Removal of unexec support from glibc malloc

[Paul Eggert]

Wolfgang Jenkner wrote:
> Isn't hybrid malloc the portable version of this?  A patch series for
> this already exists (bug##22086), but Paul said that he wanted to get
> rid of src/gmalloc.c even for allocations before dumping, IIUC.

Yes, that's what I'd like to do in the long run. Emacs shouldn't be in the 
malloc business.

If the hybrid malloc approach suffices to get Emacs to work with the new glibc 
API (and assuming Emacs doesn't already work with the new glibc API), then we 
could install that patch series into emacs-25 rather than trying to improve it 
for after Emacs 25, on the theory that people will want to build Emacs 25 in 
GNU/Linux environments with the new glibc and that this boosts the urgency of 
the hybrid malloc.

Florian, I understand that the new glibc implementation doesn't exist yet, so we 
can't test Emacs on it. However, is the new glibc API documented anywhere? 
Perhaps we could try to check via code inspection that Emacs works under 
GNU/Linux both with the current and the new glibc API, either now or with the 
hybrid malloc patches installed.

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/18/2016 08:50 PM, Paul Eggert wrote:

> 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.

The main problem is that the heap is laid out in a particular way.  If
we change the heap layout in a glibc update (which we want to do on
powerpc for conformance reasons, for example), then old Emacs binaries
will not start anymore.  We can work around that with compatibility
symbols, but when we fix that, I want to decouple Emacs binaries from
these glibc implementation details, to avoid a repeat of the entire
exercise.

This is less of a problem if Emacs never frees a pointer after dump that
it has allocated before dump.  But I think this can happen (otherwise,
all this would be quite easy to address).

Florian

Re: Removal of unexec support from glibc malloc

[Ali Bahrami]

On 1/18/16 12:20 PM, John Wiegley wrote:
>>>>>> Florian Weimer <fweimer@redhat.com> 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

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/18/2016 08:24 PM, Paul Eggert wrote:

> Can you explain the problem in more detail? What are the symptoms if you
> do the following with the next-generation glibc API?
> 
> git clone --branch emacs-25 git://git.savannah.gnu.org/emacs.git
> cd emacs
> ./autogen.sh
> ./configure
> make

This doesn't work with current glibc and the current Emacs configure.ac
file.  It doesn't seem possible to get rid of the dlmalloc detection
without editing configure.ac.

> Is there some way that Emacs developers (who are typically not glibc
> experts) can easily test with the next-generation glibc API?

I don't have the new API yet.  It will likely consist of the C and POSIX
APIs exclusively (that is, no hooks, no malloc_set_state).  The easiest
way is likely to trick configure into believing that it's not on glibc
malloc.  If the resulting post-dump binary runs under valgrind or with
another malloc implementation such as jemalloc or tcmalloc preloaded, it
will likely work with future glibc versions.

I did the configure.ac edit, and Emacs chose to use gmalloc.c, and the
resulting binary works, even under valgrind.  Looking at its symbols,
it's immune to malloc preloading due to the built-in malloc definition.
 This should continue to work, but you now have to maintain your own malloc.

Florian

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/18/2016 11:27 PM, Joseph Myers wrote:
> On Mon, 18 Jan 2016, Daniel Colascione wrote:
> 
>> On 01/18/2016 11:54 AM, Zack Weinberg wrote:
>>> On Mon, Jan 18, 2016 at 2:47 PM, Daniel Colascione <dancol@dancol.org> wrote:
>>>>
>>>> As long as the ABI support is there, we can keep using the "separate
>>>> malloc implementation" even if glibc doesn't cooperate by providing
>>>> convenient headers to access it.
>>>
>>> Clarification: it will not be possible to link new executables against
>>> the symbols in question. (This is what a "compat symbol" in glibc is -
>>> available only to existing binaries, not to new invocations of ld.)
>>
>> Oh, with a linker script or other hackery, I'm sure I could make it
>> available to new invocations of ld. It's just bytes.
> 
> Being a compat symbol also means that future architecture ports and ABIs 
> don't include the functionality at all.

And even if the symbol is still there, the the version you need to
supply will be architecture-specific.  Don't do this. :)

Florian

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On 01/18/2016 11:42 PM, Paul Eggert wrote:

> Florian, I understand that the new glibc implementation doesn't exist
> yet, so we can't test Emacs on it. However, is the new glibc API
> documented anywhere? Perhaps we could try to check via code inspection
> that Emacs works under GNU/Linux both with the current and the new glibc
> API, either now or with the hybrid malloc patches installed.

See my other message.  I'm attaching the configure.ac patch I used.

With a bit of luck, newer valgrind versions will even recognize the
interposed malloc, simplifying leak detection.

There could be glitches due to the way gmalloc.c works.  And it's
unusual not to interpose malloc_usable_size when you interpose the other
functions.  valign and pvalign are missing too (but really obscure).

Florian

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-no-dlmalloc.patch --]
[-- Type: text/x-patch; name="emacs-no-dlmalloc.patch", Size: 939 bytes --]

diff --git a/configure.ac b/configure.ac
index ddf0f5f..95bdc0c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2089,24 +2089,9 @@ fi
 
 # Does the opsystem file prohibit the use of the GNU malloc?
 # Assume not, until told otherwise.
-GNU_MALLOC=yes
-
-AC_CACHE_CHECK(
-  [whether malloc is Doug Lea style],
-  [emacs_cv_var_doug_lea_malloc],
-  [emacs_cv_var_doug_lea_malloc=no
-   dnl Hooks do not work with address sanitization.
-   if test "$emacs_cv_sanitize_address" != yes; then
-     AC_LINK_IFELSE(
-       [AC_LANG_PROGRAM(
-	  [[#include <malloc.h>
-	    static void hook (void) {}]],
-	  [[malloc_set_state (malloc_get_state ());
-	    __after_morecore_hook = hook;
-	    __malloc_initialize_hook = hook;]])],
-       [emacs_cv_var_doug_lea_malloc=yes])
-   fi])
-doug_lea_malloc=$emacs_cv_var_doug_lea_malloc
+GNU_MALLOC=no
+
+doug_lea_malloc=no
 
 system_malloc=$emacs_cv_sanitize_address
 

Re: Removal of unexec support from glibc malloc

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

>>>>> Ali Bahrami <ali_gnu2@emvision.com> writes:

> 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.

I agree with what you're saying. Several voices have already voiced that we'd
like to move away from the complexity of "being in the malloc business"
(thanks, Paul). Now I'd like to know what it will take to get us there.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Removal of unexec support from glibc malloc

[Wolfgang Jenkner]

On Mon, Jan 18 2016, Ali Bahrami wrote:

> 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.

But I guess you loaded pre-compiled elisp files on those machines?

Re: Removal of unexec support from glibc malloc

[Ali Bahrami]

On 1/18/16 5:45 PM, Wolfgang Jenkner wrote:
> On Mon, Jan 18 2016, Ali Bahrami wrote:
>
>> 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.
>
> But I guess you loaded pre-compiled elisp files on those machines?
>

To the best of my recollection, it used the pre-compiled .elc files.

Byte compiling the lisp is completely portable and under emacs's
control, so it doesn't have the same sort of issues as unexec.

- Ali

Re: Removal of unexec support from glibc malloc

[Dmitry Gutov]

On 01/19/2016 01:45 AM, Ali Bahrami wrote:

> Before you fight to to save unexec, I'd encourage you to measure the
> impact, and see if it still matters.

As a rough measurement, 'src/emacs -Q' takes ~0.5s to launch on my 
machine. 'src/temacs -Q` takes ~5.5s.

It seems not only machines have become faster, Emacs has grown quite a 
bit, too. :)

Re: Removal of unexec support from glibc malloc

[Ken Raeburn]

> On Jan 18, 2016, at 20:14, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 01/19/2016 01:45 AM, Ali Bahrami wrote:
> 
>> Before you fight to to save unexec, I'd encourage you to measure the
>> impact, and see if it still matters.
> 
> As a rough measurement, 'src/emacs -Q' takes ~0.5s to launch on my machine. 'src/temacs -Q` takes ~5.5s.
> 
> It seems not only machines have become faster, Emacs has grown quite a bit, too. :)

It’s also pretty aggressive about garbage collection after loading any code before the unexec.  Presumably that’s to minimize the storage needed for the shared on-disk image.

Try removing the after-load-functions hook in loadup.el that invokes GC, and the explicit GC calls.  Also maybe bump up gc-cons-threshold by an order of magnitude.  (Just until loading finishes, if you like.)

Ken

Re: Removal of unexec support from glibc malloc

[Ali Bahrami]

On 1/18/16 6:14 PM, Dmitry Gutov wrote:
> On 01/19/2016 01:45 AM, Ali Bahrami wrote:
>
>> Before you fight to to save unexec, I'd encourage you to measure the
>> impact, and see if it still matters.
>
> As a rough measurement, 'src/emacs -Q' takes ~0.5s to launch on my machine. 'src/temacs -Q` takes ~5.5s.
>
> It seems not only machines have become faster, Emacs has grown quite a bit, too. :)


    Maybe. I probably should have tried it before posting. :-)

Or maybe there are too many variables involved, and
comparing software from different decades usefully
is hard.

I just did that here, and my temacs -Q time is roughly
the same as yours. I wonder how much of that is simply finding
the files, opening them, and pulling in the bytes, and how
much is emacs loading those bytes into its internal data
structures? If it's mainly file I/O, then something that
gets those aggregated bytes into emacs quickly at startup,
but still requires emacs to go through them and load its
data structures might be nearly as fast.

Ways to do that might involve mmap, or having a teamcs-like
first stage write a C file containing a data array with the
compiled lisp bytecodes, which could then be compiled and
linked into a second stage emacs.

For that matter, I wonder how much time could be shaved
if temacs didn't announce each loaded file in the minibuffer
at startup?

- Ali

Re: Removal of unexec support from glibc malloc

[Dmitry Gutov]

On 01/19/2016 04:44 AM, Ken Raeburn wrote:

> Try removing the after-load-functions hook in loadup.el that invokes GC, and the explicit GC calls.

That brings the loading time down to ~4.8 seconds.

> Also maybe bump up gc-cons-threshold by an order of magnitude.

And that doesn't seem any appreciable effect here.

Re: Removal of unexec support from glibc malloc

[Dmitry Gutov]

On 01/19/2016 04:45 AM, Ali Bahrami wrote:
> I wonder how much of that is simply finding
> the files, opening them, and pulling in the bytes, and how
> much is emacs loading those bytes into its internal data
> structures?

I'd venture a guess that it's mostly the latter: I can Grep through the 
files in question much faster than that.

> For that matter, I wonder how much time could be shaved
> if temacs didn't announce each loaded file in the minibuffer
> at startup?

Much less than 4 seconds, probably.

Re: Removal of unexec support from glibc malloc

[Ken Raeburn]

> On Jan 18, 2016, at 20:59, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 01/19/2016 04:44 AM, Ken Raeburn wrote:
> 
>> Try removing the after-load-functions hook in loadup.el that invokes GC, and the explicit GC calls.
> 
> That brings the loading time down to ~4.8 seconds.
> 
>> Also maybe bump up gc-cons-threshold by an order of magnitude.
> 
> And that doesn't seem any appreciable effect here.

Huh.  Disappointing.  When I was poking at CANNOT_DUMP startup time about a year ago, I seem to recall that these helped, but I don’t remember how much.  A couple other things though:

* Since you (presumably) didn’t configure with CANNOT_DUMP, temacs may still be making “pure” copies of objects.  But I just tried rebuilding with CANNOT_DUMP, and temacs aborted in bidi_initialize; I’m guessing it wants to use something initialized by Lisp code that hasn’t run yet.

* If you’re on a Mac, loading elisp is extra slow, thanks to getc() calling mutex functions that are very slow (at least compared to the glibc versions); I tried out a workaround using getc_unlocked, which seemed to help a lot.

Ken

Re: Removal of unexec support from glibc malloc

[Dmitry Gutov]

On 01/19/2016 06:10 AM, Ken Raeburn wrote:

> * If you’re on a Mac, loading elisp is extra slow, thanks to getc() calling mutex functions that are very slow (at least compared to the glibc versions); I tried out a workaround using getc_unlocked, which seemed to help a lot.

Not my case, Ubuntu here.

Anyway, the simple approach seems to have failed, let's leave the next 
step to more knowledgeable people.

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Florian Weimer <fweimer@redhat.com>
> Date: Mon, 18 Jan 2016 23:44:54 +0100
> Cc: GNU C Library <libc-alpha@sourceware.org>,
> 	Emacs Development <Emacs-devel@gnu.org>
> 
> This is less of a problem if Emacs never frees a pointer after dump that
> it has allocated before dump.  But I think this can happen (otherwise,
> all this would be quite easy to address).

Yes, it can and does happen, although not much.

Re: Removal of unexec support from glibc malloc

[Paul Eggert]

Florian Weimer wrote:
> See my other message.  I'm attaching the configure.ac patch I used.

Ah, in that case (as Joseph pointed out) in 2014 I mentioned a simple way to 
test this approach, which requires no patch to Emacs or to glibc. Configure 
Emacs this way:

./configure emacs_cv_var_doug_lea_malloc=no

This causes Emacs to use its own malloc implementation. Back then I observed 
that this hurt performance somewhat (text 0.5% larger, data 7.6% larger, 14% 
more CPU time on my usual benchmark) but I did not observe any bugs; see 
<https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00542.html>.

I'll test this more, and if it doesn't have problems then we can declare the 
issue resolved, from glibc's point of view anyway. On the Emacs side we still 
have unexec cleanup to do, but the glibc change does not make this much more 
urgent than it already is, and we needn't make any changes to Emacs before Emacs 
25 comes out.

> With a bit of luck, newer valgrind versions will even recognize the
> interposed malloc, simplifying leak detection.

Wow, thanks, I didn't know that.  I have been using valgrind only on temacs (the 
undumped, slow, and hard-to-use Emacs), because valgrind doesn't work on dumped 
emacs under GNU/Linux. With the above configuration hack, valgrind works on 
dumped emacs; this is a win when debugging, and to me it's worth the performance 
hit.

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On 01/19/2016 02:44 AM, Ken Raeburn wrote:
> 
>> On Jan 18, 2016, at 20:14, Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>> On 01/19/2016 01:45 AM, Ali Bahrami wrote:
>>
>>> Before you fight to to save unexec, I'd encourage you to measure the
>>> impact, and see if it still matters.
>>
>> As a rough measurement, 'src/emacs -Q' takes ~0.5s to launch on my machine. 'src/temacs -Q` takes ~5.5s.
>>
>> It seems not only machines have become faster, Emacs has grown quite a bit, too. :)
> 
> It’s also pretty aggressive about garbage collection after loading any code before the unexec.  Presumably that’s to minimize the storage needed for the shared on-disk image.
> 
> Try removing the after-load-functions hook in loadup.el that invokes GC, and the explicit GC calls.  Also maybe bump up gc-cons-threshold by an order of magnitude.  (Just until loading finishes, if you like.)

The attached patch brings down the temacs load time to under 0.5 seconds.

The major offender is find_string_data_in_pure in src/alloc.c, and
setting purify to nil gets rid of that.  Some additional savings come
from removing the after-load-function hook in loadup.el, as you
suggested, but they are comparatively minor.

For some reason, international/characters does not load anymore, so I
dropped it for quick testing.

Florian

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fast-temacs.patch --]
[-- Type: text/x-patch; name="fast-temacs.patch", Size: 1788 bytes --]

diff --git a/lisp/loadup.el b/lisp/loadup.el
index 5f29c01..8870eb7 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -47,6 +47,8 @@
 
 ;;; Code:
 
+(setq purify-flag nil)
+
 ;; Add subdirectories to the load-path for files that might get
 ;; autoloaded when bootstrapping.
 ;; This is because PATH_DUMPLOADSEARCH is just "../lisp".
@@ -99,10 +101,6 @@
 (load "emacs-lisp/backquote")
 (load "subr")
 
-;; Do it after subr, since both after-load-functions and add-hook are
-;; implemented in subr.el.
-(add-hook 'after-load-functions (lambda (f) (garbage-collect)))
-
 (load "version")
 
 (load "widget")
@@ -168,7 +166,6 @@
 ;; This file doesn't exist when building a development version of Emacs
 ;; from the repository.  It is generated just after temacs is built.
 (load "international/charprop.el" t)
-(load "international/characters")
 (load "composite")
 
 ;; Load language-specific files.
@@ -374,11 +371,6 @@
 ;; Avoid storing references to build directory in the binary.
 (setq custom-current-group-alist nil)
 
-;; We keep the load-history data in PURE space.
-;; Make sure that the spine of the list is not in pure space because it can
-;; be destructively mutated in lread.c:build_load_history.
-(setq load-history (mapcar 'purecopy load-history))
-
 (set-buffer-modified-p nil)
 
 (remove-hook 'after-load-functions (lambda (f) (garbage-collect)))
@@ -413,10 +405,6 @@
     (message "Pure-hashed: %d strings, %d vectors, %d conses, %d bytecodes, %d others"
              strings vectors conses bytecodes others)))
 
-;; Avoid error if user loads some more libraries now and make sure the
-;; hash-consing hash table is GC'd.
-(setq purify-flag nil)
-
 (if (null (garbage-collect))
     (setq pure-space-overflow t))
 

Re: Removal of unexec support from glibc malloc

[Ken Raeburn]

> The attached patch brings down the temacs load time to under 0.5 seconds.

Excellent, I was pretty sure it should still be possible; I’d gotten to around there before.

Still not good enough, IMNSHO, but all we have to do now is shave another half second off…. :-)

> 
> The major offender is find_string_data_in_pure in src/alloc.c, and
> setting purify to nil gets rid of that.  Some additional savings come
> from removing the after-load-function hook in loadup.el, as you
> suggested, but they are comparatively minor.

Thinking back some more on my experiments last year, I guess I’m not surprised. I wish I’d made more notes. I think I started with configuring CANNOT_DUMP (which would disable the purify code) and profiled it, and the first obvious time sink to tackle was the excessive mutex calls (a Mac specific issue, AFAIK, though it’s possible glibc/Linux and others could benefit a little); after that, tweaking the GC helped me push the startup time down a little bit further, but it was a smaller issue.

Ken

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/19/2016 07:31 AM, Paul Eggert wrote:

>> With a bit of luck, newer valgrind versions will even recognize the
>> interposed malloc, simplifying leak detection.
> 
> Wow, thanks, I didn't know that.  I have been using valgrind only on
> temacs (the undumped, slow, and hard-to-use Emacs), because valgrind
> doesn't work on dumped emacs under GNU/Linux.

With the new interposing-aware valgrind, valgrind still works, but
there's a memory allocation failure because valgrind detects an invalid
realloc and makes it return NULL, instead of forwarding it to the
implementation.

We're looking at this to see if it's easy to fix in valgrind.

Florian

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/19/2016 10:27 AM, Florian Weimer wrote:
> On 01/19/2016 07:31 AM, Paul Eggert wrote:
> 
>>> With a bit of luck, newer valgrind versions will even recognize the
>>> interposed malloc, simplifying leak detection.
>>
>> Wow, thanks, I didn't know that.  I have been using valgrind only on
>> temacs (the undumped, slow, and hard-to-use Emacs), because valgrind
>> doesn't work on dumped emacs under GNU/Linux.
> 
> With the new interposing-aware valgrind, valgrind still works, but
> there's a memory allocation failure because valgrind detects an invalid
> realloc and makes it return NULL, instead of forwarding it to the
> implementation.
> 
> We're looking at this to see if it's easy to fix in valgrind.

This will not work until the undumping code iterates over all heap
objects and marks them with VALGRIND_MALLOCLIKE_BLOCK.  It's not exactly
trivial (but not that hard, either).  There might be secondary breakage
after that.

Florian

Re: Removal of unexec support from glibc malloc

[Wolfgang Jenkner]

On Mon, Jan 18 2016, Paul Eggert wrote:

> ./configure emacs_cv_var_doug_lea_malloc=no
>
> This causes Emacs to use its own malloc implementation. Back then
> I observed that this hurt performance somewhat (text 0.5% larger, data
> 7.6% larger, 14% more CPU time on my usual benchmark) but I did not
> observe any bugs; see
> <https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00542.html>.

IIUC, this means that either mmap or src/ralloc.c is needed for memory
reallocations, and those do have very annoying performance problems in
non-contrived cases, please see bug#19393 for such a scenario.

The discussion about the performance problem begins at

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19393#46

Should Glibc API be changed?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I have written to the Glibc maintainers to ask them to discuss this
with John, but I think that a proposal for such a big incompatibility
calls for a very broad discussion before any decisions are made.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Ali Bahrami <ali_gnu2@emvision.com>
> 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).

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Ali Bahrami <ali_gnu2@emvision.com>
> Date: Mon, 18 Jan 2016 18:45:29 -0700
> 
> I just did that here, and my temacs -Q time is roughly
> the same as yours. I wonder how much of that is simply finding
> the files, opening them, and pulling in the bytes, and how
> much is emacs loading those bytes into its internal data
> structures?

We pre-load around 110 files, totaling about 4.5MB into temacs, so I
very much doubt that these 5 sec could be mostly I/O, as 50 msec per
a 40 KB file is way too much for just I/O.

Re: Should Glibc API be changed?

[Florian Weimer]

On 01/19/2016 02:52 PM, Richard Stallman wrote:

> I have written to the Glibc maintainers to ask them to discuss this
> with John, but I think that a proposal for such a big incompatibility
> calls for a very broad discussion before any decisions are made.

Richard,

I'm disappointed you chose a private mailing list for the discussion.
This doesn't really match how glibc development proceeds today.

I'm puzzled why you think this is a major change.  It only affects Emacs
and perhaps some unpublished (and therefore likely proprietary)
applications we know nothing about.

The research in the parent thread suggests that I was mistaken and Emacs
should compile just fine after removal of the API.  And as I wrote in my
initial message, this was never about removal of the ABI, so existing
Emacs binaries will keep working.

Florian

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Florian Weimer <fweimer@redhat.com>
> Date: Tue, 19 Jan 2016 08:03:16 +0100
> Cc: Ali Bahrami <ali_gnu2@emvision.com>, emacs-devel@gnu.org
> 
> For some reason, international/characters does not load anymore

Because of this snippet (in international/characters.el), no doubt:

  ;; Setting char-script-table.
  (if purify-flag
      ;; While dumping, we can't use require, and international is not
      ;; in load-path.
      (load "international/charscript")
    (require 'charscript))

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: Florian Weimer <fweimer@redhat.com>,  Eli Zaretskii <eliz@gnu.org>,  Emacs-devel@gnu.org,  GNU C Library <libc-alpha@sourceware.org>
> Date: Tue, 19 Jan 2016 14:27:21 +0100
> 
> On Mon, Jan 18 2016, Paul Eggert wrote:
> 
> > ./configure emacs_cv_var_doug_lea_malloc=no
> >
> > This causes Emacs to use its own malloc implementation. Back then
> > I observed that this hurt performance somewhat (text 0.5% larger, data
> > 7.6% larger, 14% more CPU time on my usual benchmark) but I did not
> > observe any bugs; see
> > <https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00542.html>.
> 
> IIUC, this means that either mmap or src/ralloc.c is needed for memory
> reallocations, and those do have very annoying performance problems in
> non-contrived cases, please see bug#19393 for such a scenario.
> 
> The discussion about the performance problem begins at
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19393#46

Performance problems of ralloc.c is the least of our problems.  The
real problem is that it relocates buffer text in memory when it thinks
that will allow it to coalesce small chunks of free memory into larger
chunks.  The result is subtle problems in Emacs's C code that holds C
pointers to buffer text, notably when GC strikes, but also when a
large memory allocation is requested or freed.  Some of these problems
are impossible or impractical to fix.  When these bugs happen, they
are evasive and very hard to debug.

For that reason, we made a significant effort in the last years to get
rid of ralloc.c on as many systems as we can.  Going back to using
ralloc.c more widely is really a non-starter, particularly considering
the fact that today's Emacs hackers are less proficient with C than
the (diminishing number of) old-timers, and will probably bump into
these problems much more easily.

So I really hope that the alternative of using gmalloc.c does NOT also
mean using ralloc.c on glibc-based platforms.

Using mmap is also not an attractive alternative, due to performance
problems as mentioned above.

Re: Removal of unexec support from glibc malloc

[Fabrice Popineau]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> > From: Ali Bahrami <ali_gnu2 <at> emvision.com>
> > Date: Mon, 18 Jan 2016 15:45:50 -0700
> > 

> > 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.
> 

A portable dumper would solve the unexec issue.

There was an attempt at porting the XEmacs portable dumper to GNU Emacs 
long ago:
http://www.sodan.org/~knagano/emacs/pdump/

The topic is recurrent:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2015-06/msg00771.html
https://lists.gnu.org/archive/html/bug-gnu-emacs/2015-06/msg00781.html

Fabrice

Re: Removal of unexec support from glibc malloc

[Sam Steingold]

Saving images is a standard Common Lisp feature, so all Common Lisp
implementations (GCL, CLISP, SBCL, CMUCL, ECL &c &c &c) do it.
Can't we just take their code instead of using unexec?
Thanks!
-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://palestinefacts.org http://islamexposedonline.com
http://camera.org http://ffii.org http://jihadwatch.org http://www.memritv.org
The only substitute for good manners is fast reflexes.

Re: Should Glibc API be changed?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm disappointed you chose a private mailing list for the discussion.

Of course I did.  This a sensitive issue; it is best to discuss it
without an audience.

  > I'm puzzled why you think this is a major change.  It only affects Emacs

A change that breaks other programs, and does not offer a trivial way
to fix them, is a major change.  Affecting Emacs is already plenty --
and other programs might be affected to.

  > The research in the parent thread suggests that I was mistaken and Emacs
  > should compile just fine after removal of the API.

I suspect a misunderstanding.  You may be using the term "API" in a
narrow sense.  I mean, everything about how programs can use Glibc.

This is not just about whether Emacs (and maybe other programs)
_compile_ without errors.  It's about whether they still work as
intended.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There was an attempt at porting the XEmacs portable dumper to GNU Emacs 
  > long ago:
  > http://www.sodan.org/~knagano/emacs/pdump/

Do we have copyright papers from that?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

One advantage of unexec is that you can do limited editing
with the Emacs executable even if the Lisp files are missing.
You couldn't do that with only temacs.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On 1/19/16 6:57 PM, Richard Stallman wrote:
> One advantage of unexec is that you can do limited editing
> with the Emacs executable even if the Lisp files are missing.
> You couldn't do that with only temacs.

That leads to an interesting idea—what if one were to smash all the .elc
files that temacs loads as part of the undump process and then put them
into the temacs object, maybe by relinking them in as a giant array
(portable), or by shoving them into their own section with objcopy (not
really portable)? That would make the resulting binary basically usable
without any lisp files, plus it might help with I/O speed since 100
different files don't have to be read.

-David



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4239 bytes --]

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> Cc: dgutov@yandex.ru, ali_gnu2@emvision.com, emacs-devel@gnu.org
> From: David Caldwell <david@porkrind.org>
> Date: Tue, 19 Jan 2016 23:43:00 -0800
> 
> That leads to an interesting idea—what if one were to smash all the .elc
> files that temacs loads as part of the undump process and then put them
> into the temacs object, maybe by relinking them in as a giant array
> (portable), or by shoving them into their own section with objcopy (not
> really portable)? That would make the resulting binary basically usable
> without any lisp files, plus it might help with I/O speed since 100
> different files don't have to be read.

You have described what unexec does, in some of its incarnations.  We
just put those *.elc files into a separate executable, called 'emacs',
and not in 'temacs'.

Re: Should Glibc API be changed?

[Florian Weimer]

On 01/20/2016 03:56 AM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > I'm disappointed you chose a private mailing list for the discussion.
> 
> Of course I did.  This a sensitive issue; it is best to discuss it
> without an audience.

In this case, you need to contact the GNU maintainers for glibc
directly.  (I do not have access to official GNU project records and do
not know who they are.)  The membership roster of the glibc-sc mailing
list has not been updated in recent years (I assume), and most people
there are no longer familiar with the day-to-day glibc development

Thanks,
Florian

Re: Removal of unexec support from glibc malloc

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That leads to an interesting idea—what if one were to smash all the .elc
  > files that temacs loads as part of the undump process and then put them
  > into the temacs object, maybe by relinking them in as a giant array
  > (portable), or by shoving them into their own section with objcopy (not
  > really portable)?

It sounds good in principle, but the real test is in implementing it.

If it can really be done by making them an array, that would eliminate
any issues about whether the program can always find and open the
temacs file.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That leads to an interesting idea—what if one were to smash all the .elc
  > > files that temacs loads as part of the undump process and then put them
  > > into the temacs object, maybe by relinking them in as a giant array
  > > (portable), or by shoving them into their own section with objcopy (not
  > > really portable)?

  > You have described what unexec does, in some of its incarnations.  We
  > just put those *.elc files into a separate executable, called 'emacs',
  > and not in 'temacs'.

He described a way to implement something equivalent to unexec,
but I don't think that's how our unexec works now.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Stefan Monnier]

>> This is less of a problem if Emacs never frees a pointer after dump that
>> it has allocated before dump.  But I think this can happen (otherwise,
>> all this would be quite easy to address).
> Yes, it can and does happen, although not much.

Indeed.  This said, it'd make sense to try and avoid doing it.


        Stefan

Re: Removal of unexec support from glibc malloc

[Stefan Monnier]

> As long as we're talking about work to do: I'd love for the new portable
> dumper to support dumping Emacs multiple times. I've had to put a lot of
> effort into my configuration to get Emacs to start in an acceptable
> time, and a lot of people tolerate multi-second Emacs startup times.
> It'd be nice if we could dump Emacs after loading user customizations.

FWIW, this has worked in the past.


        Stefan

Re: Removal of unexec support from glibc malloc

[Stefan Monnier]

> This is the prior notice.  I'm writing to you before the patch is even
> written.  This is not something which is going to happen overnight.

I'm surprised.  I would have sworn that there had been a prior
prior notice (tho maybe it was more "testing the waters", less
assertive).


        Stefan

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 23 Jan 2016 00:49:02 -0500
> Cc: libc-alpha@sourceware.org
> 
> >> This is less of a problem if Emacs never frees a pointer after dump that
> >> it has allocated before dump.  But I think this can happen (otherwise,
> >> all this would be quite easy to address).
> > Yes, it can and does happen, although not much.
> 
> Indeed.  This said, it'd make sense to try and avoid doing it.

AFAICS, it happens due to the following:

  . We call regex.c functions, which reuse an allocated buffer,
    extending it (via realloc) as needed; that buffer gets frozen with
    malloc arena used during dumping

  . We delete the terminal frame used by temacs and free its resources

  . Not 100% sure, but I think we also release/reallocate some
    font-related stuff

It's easy to catch all those cases by setting a breakpoint on realloc
and free during startup.

Re: Removal of unexec support from glibc malloc

[Michael Sperber]

Richard Stallman <rms@gnu.org> writes:

> Do we have copyright papers from that?

For the original XEmacs dumper, you might want to ask Marcus Crestani,
who wrote it.  He's on the cc.

-- 
Regards,
Mike

Re: Removal of unexec support from glibc malloc

[Stefan Monnier]

> AFAICS, it happens due to the following:
>   . We call regex.c functions, which reuse an allocated buffer,
>     extending it (via realloc) as needed; that buffer gets frozen with
>     malloc arena used during dumping
>   . We delete the terminal frame used by temacs and free its resources
>   . Not 100% sure, but I think we also release/reallocate some
>     font-related stuff
> It's easy to catch all those cases by setting a breakpoint on realloc
> and free during startup.

I guess that's what happens in practice, but I'd be surprised if there
aren't more cases that can happen in theory.  I'm thinking of memory
areas allocated for Elisp data which will *usually* stay live during the
lifetime of Emacs, but which could become free if we do things like
re-define some core datastructure (e.g. I'm thinking of things like
(setq global-map (copy-keymap global-map)).


        Stefan

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  libc-alpha@sourceware.org
> Date: Sat, 23 Jan 2016 10:29:33 -0500
> 
> > AFAICS, it happens due to the following:
> >   . We call regex.c functions, which reuse an allocated buffer,
> >     extending it (via realloc) as needed; that buffer gets frozen with
> >     malloc arena used during dumping
> >   . We delete the terminal frame used by temacs and free its resources
> >   . Not 100% sure, but I think we also release/reallocate some
> >     font-related stuff
> > It's easy to catch all those cases by setting a breakpoint on realloc
> > and free during startup.
> 
> I guess that's what happens in practice, but I'd be surprised if there
> aren't more cases that can happen in theory.

Right now, anything can happen in theory, because we don't generally
write specialized code for temacs, we use the "normal" code, both in
Lisp and in C.  The only significant difference is the use of 'pure'.

> I'm thinking of memory areas allocated for Elisp data which will
> *usually* stay live during the lifetime of Emacs, but which could
> become free if we do things like re-define some core datastructure
> (e.g. I'm thinking of things like (setq global-map (copy-keymap
> global-map)).

I don't understand the last part of this at all.

AFAIU, the problem is not with Lisp data, the problem is with memory
allocations on the C level that are not on behalf of Lisp data.  We
need to find a way of doing that without relying on that data be
fee'able after dumping.

Re: Removal of unexec support from glibc malloc

[Marcus Crestani]

>>>>>"MS" == Michael Sperber <sperber@deinprogramm.de> writes:
MS> For the original XEmacs dumper, you might want to ask Marcus Crestani,
MS> who wrote it.  He's on the cc.

I just rewrote parts of the dumper to make it work with XEmacs'
incremental garbage collector.  The original XEmacs dumper was written
by Olivier Galibert (cc'd).

As for my contributions, I'm willing to sign the copyright papers if
required.

-- 
Marcus

Re: Removal of unexec support from glibc malloc

[Stefan Monnier]

> I don't understand the last part of this at all.
> AFAIU, the problem is not with Lisp data, the problem is with memory
> allocations on the C level that are not on behalf of Lisp data.  We
> need to find a way of doing that without relying on that data be
> fee'able after dumping.

The part you didn't understand was specifically referring to the fact
that preloaded Lisp data can also be freed (by the GC) and that in turn
can also lead to calls to `free'.


        Stefan

Re: Removal of unexec support from glibc malloc

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > AFAICS, it happens due to the following:

  >   . We call regex.c functions, which reuse an allocated buffer,
  >     extending it (via realloc) as needed; that buffer gets frozen with
  >     malloc arena used during dumping

  >   . We delete the terminal frame used by temacs and free its resources

  >   . Not 100% sure, but I think we also release/reallocate some
  >     font-related stuff

  > It's easy to catch all those cases by setting a breakpoint on realloc
  > and free during startup.

It may be a pain to fix them if they happen inside libraries.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/23/2016 06:56 AM, Stefan Monnier wrote:
>> This is the prior notice.  I'm writing to you before the patch is even
>> written.  This is not something which is going to happen overnight.
> 
> I'm surprised.  I would have sworn that there had been a prior
> prior notice (tho maybe it was more "testing the waters", less
> assertive).

Yes, there was a discussion in 2014 of which I wasn't aware when I wrote
this.

  <https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00542.html>

And the autoconf test for dlmalloc has been printing a deprecation
warning for a couple of years now.

Florian

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/23/2016 11:52 PM, Richard Stallman wrote:

[realloc/free of a dumped heap object]

> It may be a pain to fix them if they happen inside libraries.

I think the dump-and-reload cycle resets global variables defined in
libraries as long as they are not referenced by the main program.  This
means libraries have difficulties to retain references to objects
allocated before the dump.

If Emacs retains such references and passes them to a library, such
boundary-crossing heap operations could still happen.  But some
libraries will get very confused if they are handed an object while
their internal state says they have not created any objects yet.  (Which
is how we got __malloc_get_state and __malloc_set_state, I assume.)

Has it already happened that an innocent-looking library change causes
existing Emacs binaries to break?  Apart from when glibc tried to fix
the incorrect object alignment on 32-bit PowerPC?

Florian

Re: Removal of unexec support from glibc malloc

[Stefan Monnier]

>>> [realloc/free of a dumped heap object]
>> It may be a pain to fix them if they happen inside libraries.
> I think the dump-and-reload cycle resets global variables defined in
> libraries as long as they are not referenced by the main program.  This
> means libraries have difficulties to retain references to objects
> allocated before the dump.

I agree that it's unlikely that we'll bump into problems where there's
a realloc/free of dumped objects that happens completely inside a library.

More specifically, I wouldn't worry about this problem.


        Stefan

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, libc-alpha@sourceware.org,
>         monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Florian Weimer <fweimer@redhat.com>
> Date: Tue, 26 Jan 2016 23:17:35 +0100
> 
> On 01/23/2016 11:52 PM, Richard Stallman wrote:
> 
> [realloc/free of a dumped heap object]
> 
> > It may be a pain to fix them if they happen inside libraries.
> 
> I think the dump-and-reload cycle resets global variables defined in
> libraries as long as they are not referenced by the main program.  This
> means libraries have difficulties to retain references to objects
> allocated before the dump.
> 
> If Emacs retains such references and passes them to a library, such
> boundary-crossing heap operations could still happen.  But some
> libraries will get very confused if they are handed an object while
> their internal state says they have not created any objects yet.  (Which
> is how we got __malloc_get_state and __malloc_set_state, I assume.)
> 
> Has it already happened that an innocent-looking library change causes
> existing Emacs binaries to break?  Apart from when glibc tried to fix
> the incorrect object alignment on 32-bit PowerPC?

AFAIK, Emacs has no reason to call any libraries in temacs except libc
(and its logical extensions, like libm).

Re: Removal of unexec support from glibc malloc

[Florian Weimer]

On 01/27/2016 04:38 AM, Eli Zaretskii wrote:

> AFAIK, Emacs has no reason to call any libraries in temacs except libc
> (and its logical extensions, like libm).

ELF constructors still run.  Whether their effects are visible across
dumps depends on which symbols are referenced from the main program.
All this is rather brittle.

Florian

Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> Cc: rms@gnu.org, libc-alpha@sourceware.org, monnier@iro.umontreal.ca,
>         emacs-devel@gnu.org
> From: Florian Weimer <fweimer@redhat.com>
> Date: Wed, 27 Jan 2016 10:04:33 +0100
> 
> > AFAIK, Emacs has no reason to call any libraries in temacs except libc
> > (and its logical extensions, like libm).
> 
> ELF constructors still run.

By "ELF constructors", do you mean the .ctors and .init sections?  If
so, those that belong to the libc startup code are what I called
"logical extensions of libc" above.  And if you mean such sections in
3rd party libraries, we haven't met such libraries yet.

> Whether their effects are visible across dumps depends on which
> symbols are referenced from the main program.  All this is rather
> brittle.

It works well in practice, though, have been working for 3 decades.

And that's not the most "brittle" stuff I bumped into while working on
Emacs, btw.  If you are old enough, you might remember the days when
all the major supported platforms used gmalloc+ralloc in Emacs.  In
those days there was a rule that you couldn't call libc functions that
might call 'malloc' internally, if you passed pointers to buffer text
to those functions -- because ralloc would sometimes relocate buffer
text as side effect of 'malloc'/'realloc' calls, and by doing that
invalidate those pointers.  The first serious bug I needed to debug
when I started hacking Emacs, 20 years ago, was caused by a call to
'write' in write-region, which triggered such relocation, because the
particular libc involved had the audacity to call 'malloc' inside
'write' for whatever reasons, something Emacs code never expected,
since why would 'write' call 'malloc'?  Now, _that_ is something I'd
call "brittle".  And yet we lived with this for many years; when I
astonishingly described my findings to RMS back then, his answer was
basically "tough: that's what ralloc does, and it cannot be helped".

The fear of static constructors (which AFAIK never materialized) pales
in comparison, wouldn't you agree?

I'm not saying we shouldn't work towards removing these issues, but
it's not like we are faint at heart in these matters.

Re: Removal of unexec support from glibc malloc

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think the dump-and-reload cycle resets global variables defined in
  > libraries as long as they are not referenced by the main program.  This
  > means libraries have difficulties to retain references to objects
  > allocated before the dump.

Variables allocated by static libraries are stored like variables
allocated in any other file.  Their value should be dumped.

I don't know what happens with shared libraries, but

  >   This
  > means libraries have difficulties to retain references to objects
  > allocated before the dump.

if that were true, we would see enormous problems, so I think it
must not be true.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think adopting a portable undumping scheme that adds the data into a
copy of the emacs executable so it appears as an array in core
would be ideal.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Removal of unexec support from glibc malloc

[Paul Eggert]

Paul Eggert wrote:
> I'll test this more, and if it doesn't have problems then we can declare the
> issue resolved, from glibc's point of view anyway.

I simulated building current Emacs on future glibc by running './configure 
emacs_cv_var_doug_lea_malloc=no', which tells 'configure' to assume that the C 
library does not have the GNU malloc extensions. Although the code still seemed 
to work, there were some compile-time errors that suggested trouble; for 
example, glibc's API for the malloc hooks disagree with Emacs's replacement. To 
fix this I would like to install the set of patches discussed for Bug#22086, here:

http://bugs.gnu.org/22086#104