From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Time to drop the pre-dump phase in the build? Date: Fri, 10 Jan 2014 19:37:32 -0800 Message-ID: <52D0BC7C.2000700@dancol.org> References: <20140110191530.5772E38019B@snark.thyrsus.com> <52D071EC.4090607@dancol.org> <52D08B37.5090505@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389411513 16632 80.91.229.3 (11 Jan 2014 03:38:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 03:38:33 +0000 (UTC) Cc: "Eric S. Raymond" , stephen@xemacs.org, Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 11 04:38:40 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1pPB-0003AB-RV for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 04:38:37 +0100 Original-Received: from localhost ([::1]:59983 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1pPB-0007FR-AU for ged-emacs-devel@m.gmane.org; Fri, 10 Jan 2014 22:38:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1pP3-0007FK-CY for emacs-devel@gnu.org; Fri, 10 Jan 2014 22:38:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1pOx-0005qI-7Z for emacs-devel@gnu.org; Fri, 10 Jan 2014 22:38:29 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:43401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1pOw-0005qC-Qq for emacs-devel@gnu.org; Fri, 10 Jan 2014 22:38:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=gCGc/vcdRxX0iznzmpdy27b4Giod0Wj129fP/UsmtRk=; b=hler8K5GCa5wjm7518AYIZHWovxUEWtOX4MUKpgAv+D3FfeukcFIvHATJSPkPqRtYOnAx+4GX6gSKcrs2mCKke2XBkN367mPaWxWRgOlY1xiMZs8/Gvsy2MhGtCBhU7WkrvrX+cffPCfDtAv7mIQWKIOQ69EjFrlxI8zuIqNvlMEvFYjiH8TMcyj19TxCYLfTWtxiDKo5zPMQTUxK6vnxqdLO8B3l4JRX1ktGw4gr4oEk1eR6HLJXKIg28VrnnGxO8zwziTg5HPpnnpREISZrZuvWtNnqnbCy2bcF5vwz+m8pKqBAdLR6iK6ApesH5ISEc51qScTzw0bjsCI1y/xNQ==; Original-Received: from [173.252.71.189] (helo=[172.20.16.184]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W1pOu-0001Oy-2r; Fri, 10 Jan 2014 19:38:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168058 Archived-At: On 01/10/2014 06:58 PM, Stefan Monnier wrote: >>>> That's why the XEmacs portable dumper is better than the current Emacs >>>> setup. >>> Right, a portable dumper would be nice to have. >>> Tho I don't know enough of the details to know what are the downsides >>> (e.g. does it require relocation? If so that means the file can't just >>> be mmap'd read-only and shared between processes, right?). >> If I'm reading the XEmacs Internals documentation properly, pdump *may* >> require relocation, but not if the offset at which the dumpfile is loaded >> happens to match the offset at which it's loaded. That's about as good as >> you can ask for. > > Which begs the question: when is it the case that the offset matches? > Can we assume it to be the common case? Someone who actually uses XEmacs can probably provide better commentary (+ Stephen), but I imagine that in a 64-bit address space, you'll pretty likely be able to map the dump file in the same place every time. On a 32-bit system with ASLR, maybe not as often. Cygwin has similar problems involving fork. Another possibility is to just allocate enough space in the emacs image itself in BSS, then replace that mapping with a view of the dump file. (This way, we always map the dump file at the same place relative to the emacs image base). Or we can make the dump file a section in the image, but at that point, we're starting to talk about portability problems again. By the way: is it me, or are we dirtying far too much of the current emacs image? On my Emacs, we're dirtying (and COWing) 8MB; if I make Fgarbage_collect a no-op, that drops to 4MB.