From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 29 Nov 2016 13:19:53 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480454453 16248 195.159.176.226 (29 Nov 2016 21:20:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 21:20:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 22:20:49 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cBppV-000394-N8 for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 22:20:46 +0100 Original-Received: from localhost ([::1]:39329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBppZ-0005kN-I4 for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 16:20:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBpoo-0005jM-Tz for emacs-devel@gnu.org; Tue, 29 Nov 2016 16:20:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBpon-0000TP-SS for emacs-devel@gnu.org; Tue, 29 Nov 2016 16:20:02 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:56332) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBpon-0000Sj-Ez for emacs-devel@gnu.org; Tue, 29 Nov 2016 16:20:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=MZVvhYKgGr9W7rSJgqp3lfAGSXldtSkg6UgjwAYIDco=; b=raABSpv/ySq9WoFFQHTJVAHBIe1LcX2xjn5LX2tX4lAm8+NSmp9HtTnnqpaKf2SlUjd+UVD1KJLWOzdcqatlInF23it5B07vxK/qgcNcJn00eH5SxWV1dU3vsKL+zV7+IeAxXlVXkcBnuAqmhv2a2m0KQIP6knNu9wl6v13YGMLytXjWgvxU+LFtCerOgyrgk/NdAvuH+hV/cUe922AO0cZgrLGhQt+vTwWydKXzw5dLw3n6si61xAlKX7N/6SyHAzcRhyqoHp+aoTyChngHrK0roulLayNAw2Zm5THmKoen/Nq3OTL0IVf4dy7y1TvChWqskypGtKwZ7s6ouP/CrQ==; Original-Received: from [2620:0:1008:1101:a803:88c3:331:8b1] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cBpol-0004Xx-QX; Tue, 29 Nov 2016 13:19:59 -0800 In-Reply-To: (Stefan Monnier's message of "Tue\, 29 Nov 2016 08\:06\:56 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:209770 Archived-At: On Tue, Nov 29 2016, Stefan Monnier wrote: >> run. With a non-PIC executable, you can do a pretty good job of that >> and get performance a bit better than unexec, in theory. > > Got me curious: how/why could it be even better than unexec? With unexec, we're stuck with whatever heap layout malloc gives us, and whenever we modify a byte within this heap image, the operating system has to make a copy of that byte's host page and map that copy back into our address space. (That is, we take a copy-on-write fault.) Pure allocation partially, but not completely, addresses this overhead. With the portable dumper, *we* choose the layout and we can do things like put strings and other unlikely-to-change bits in part of the file that probably won't get COW faults. We also avoid the need to store malloc data structures. At runtime, we store the mark bits for objects in the pdumper image in a contiguous dedicated memory area instead of mutating the image, further reducing the number of COW faults we need to incur. With pdumper and a non-PIC Emacs, you'll only pay for COW faults on the lisp objects you actually modify. Even *with* a PIC Emacs (which I hope is the default, because ASLR greatly improves security), we can get these savings if mmap(BASE_ADDRESS_STORED_IN_DUMP, ...) succeeds and we can map the dump where we want. If we can't map the dump where we want, we'll just relocate it. Alternatively, if we're not memory-mapping, we can compress the dump file --- that's much harder to do with unexec.