From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.comp.lib.glibc.alpha,gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Mon, 18 Jan 2016 11:50:31 -0800 Message-ID: <569D4207.4060209@cs.ucla.edu> References: <569CDB81.6040600@redhat.com> <569D3BE0.6050103@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453146641 9084 80.91.229.3 (18 Jan 2016 19:50:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 19:50:41 +0000 (UTC) To: Florian Weimer , GNU C Library , Emacs Development Original-X-From: libc-alpha-return-66360-glibc-alpha=m.gmane.org@sourceware.org Mon Jan 18 20:50:41 2016 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aLFp1-0004pA-UB for glibc-alpha@plane.gmane.org; Mon, 18 Jan 2016 20:50:40 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=aiHzE+5pVeZbJ6KX GLi1IQvlaqmEBXp6A7xJ1quB9Bxx1AE+Lmo6xbsr8plezhb57DXpx/68pFU4zpoN dPyEIr5dFSdeFnfXuCrftMsz0E+hEI3aVmTq/GD2itWgrWGH1+Kdli5LtpOUEMHQ F4eEqKy5/7yOGPj0a30O8OP5c8I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=7vLbPWsvZAP2IJrYS/SXJS dY+6U=; b=LT/L4hqMsHccVRVSHtG6VmR2vQlkUbV0vocguVMs3mh80pOdQpCMxM /m85GuE2MstftjrW060BKHHZs8vDCzH6Z1kvcPSfnFhXcm9xMeQYigxxUV0v4mx+ VX6MpFhH0cMy31sH6kFZMU6+JGNzF2aUuMnJQXt5JafJ3jpjlQuZk= Original-Received: (qmail 59964 invoked by alias); 18 Jan 2016 19:50:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 59940 invoked by uid 89); 18 Jan 2016 19:50:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1794, living, Removal X-HELO: zimbra.cs.ucla.edu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:58643 gmane.emacs.devel:198278 Archived-At: 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.