emacs-devel
[Top][All Lists]
Advanced

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

Re: Removal of unexec support from glibc malloc


From: Daniel Colascione
Subject: Re: Removal of unexec support from glibc malloc
Date: Mon, 18 Jan 2016 14:12:21 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

On 01/18/2016 02:10 PM, Philipp Stephani wrote:
> 
> 
> Daniel Colascione <address@hidden <mailto:address@hidden>> schrieb
> am Mo., 18. Jan. 2016 um 21:05 Uhr:
> 
>     On 01/18/2016 12:02 PM, Eli Zaretskii wrote:
>     >> From: Paul Eggert <address@hidden <mailto:address@hidden>>
>     >> 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: signature.asc
Description: OpenPGP digital signature


reply via email to

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