This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Removal of unexec support from glibc malloc

From: Daniel Colascione <dancol at dancol dot org>
To: Paul Eggert <eggert at cs dot ucla dot edu>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Emacs Development <Emacs-devel at gnu dot org>
Date: Mon, 18 Jan 2016 11:54:53 -0800
Subject: Re: Removal of unexec support from glibc malloc
Authentication-results: sourceware.org; auth=none
References: <569CDB81 dot 6040600 at redhat dot com> <569D3BE0 dot 6050103 at cs dot ucla dot edu> <m2a8o2vg5x dot fsf at newartisans dot com> <569D4207 dot 4060209 at cs dot ucla dot edu>

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: signature.asc
Description: OpenPGP digital signature

References:
- Re: Removal of unexec support from glibc malloc
  - From: Paul Eggert
- Re: Removal of unexec support from glibc malloc
  - From: John Wiegley
- Re: Removal of unexec support from glibc malloc
  - From: Paul Eggert

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]