From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: pdumper's performance Date: Tue, 04 Sep 2018 12:26:32 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1536078315 31275 195.159.176.226 (4 Sep 2018 16:25:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Sep 2018 16:25:15 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: "Daniel Colascione" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 04 18:25:11 2018 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 1fxE8d-0007z7-8r for ged-emacs-devel@m.gmane.org; Tue, 04 Sep 2018 18:25:11 +0200 Original-Received: from localhost ([::1]:51719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fxEAi-00029K-QD for ged-emacs-devel@m.gmane.org; Tue, 04 Sep 2018 12:27:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fxEA7-00028u-GK for emacs-devel@gnu.org; Tue, 04 Sep 2018 12:26:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fxEA2-0006nM-Hr for emacs-devel@gnu.org; Tue, 04 Sep 2018 12:26:43 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:33633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fxEA2-0006lQ-CA for emacs-devel@gnu.org; Tue, 04 Sep 2018 12:26:38 -0400 Original-Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w84GQWQp003895; Tue, 4 Sep 2018 12:26:33 -0400 Original-Received: by lechazo.home (Postfix, from userid 20848) id AC26B6055B; Tue, 4 Sep 2018 12:26:32 -0400 (EDT) In-Reply-To: (Daniel Colascione's message of "Wed, 29 Aug 2018 22:19:27 -0700") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 3 Rules triggered SBJ_DRGSX=0.2, EDT_SA_DN_PASS=0, RV6366=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6366> : inlines <6851> : streams <1797486> : uri <2702996> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:229236 Archived-At: > Dumping objects individually instead of in blocks both simplifies the > implementation and allows for a more compact dump, as you point > out below. I understand the compactness argument, but I'm surprised it makes the implementation simpler. I'll trust you on that, tho. >> I naively thought your code would take >> cons_blocks, symbol_blocks, ... and write those blocks as-is so objects >> keep the same layout, and things like mark_maybe_object don't need to be >> changed at all. I understand this would end up writing larger dumps >> (since they would include some free objects), but I'd have expected it >> would lead to simpler code and a smaller patch. > > If we keep the mark bits out of the objects, we can avoid modifying the > object pages just for GC. In the non-PIC case, in which in principle we > don't have to relocate the dump, that means that the pages in the dump > stay clean and file-backed, not dirty, COWed, and pagefile-backed as they > would if we banged on them just for the GC. That's an efficiency win. I kind of see the benefit, but: - unlike the purespace, the dumped&restored heap is not read-only, so even with the markbits elsewhere the pages will generally not all stay clean. - the benefit you mention only applies to the case where no-relocation was needed. And I suspect that in practice keeping those pages "clean and file-backed" will very rarely make a noticeable difference anyway. - I like the idea of keeping markbits separately (XEmacs does the same, IIUC, for the needs of their incremental GC where they want to mark pages as read-only to catch writes from the mutator, while still letting the collector twiddle the mark bits). But I think this should be a separate patch and should apply to all objects rather than only the pdump'd ones. > For a future more-efficient GC, contiguous object storage with external > mark bits is probably the way to go for the entire heap. Agreed, obviously [ not only because of the text above, but also because I implemented the separate markbits for floats and cons cells ;-) ] Stefan