From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Loading tramp for dump goes into infinite regress Date: Tue, 9 Aug 2022 09:22:46 -0400 Message-ID: References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> <83r129e1op.fsf@gnu.org> <87fsi5zj9n.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bf2cdd05e5ced4da" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9170"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , emacs-devel To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 09 15:24:28 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLPDf-0002G1-CZ for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 15:24:27 +0200 Original-Received: from localhost ([::1]:58574 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLPDd-0006Pn-RU for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 09:24:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLPCI-0005eV-Fz for emacs-devel@gnu.org; Tue, 09 Aug 2022 09:23:02 -0400 Original-Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:33530) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLPCG-0007S6-RC; Tue, 09 Aug 2022 09:23:02 -0400 Original-Received: by mail-pj1-x1030.google.com with SMTP id t22-20020a17090a449600b001f617f2bf3eso1448909pjg.0; Tue, 09 Aug 2022 06:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=O2drNXyXMmMH0NXBz6jThSxqxTFQjLUiSHnpQbaTYxA=; b=bbpHhBFDVIfoe/hlIfSCXbVhcMdV1a3eqsmR5FiPvwhmgSjdxLDYoGbep1UA102yOc Zk+inmjudzsgPWfykMXQrMA4uLoVvSeEZ8pW7XINVC/fQsIb0ybdtf33V4laxzb+rfet 2bWUbwF8gvHyeTDdW5noFK86s8dA6tOMRwfu64f4EEZ9keB4NRFoDOyRo7n04cHQ2xeH dh6X6fKixxrjANrkEcxpj9heaWmXlmwBQIQWjfzJIAu+sGuh5IZiBYX/kbKQPcfL16ZW hbVrrk6sUf+FuRzzqmOmkvPwNEztL8C6QtUMEYA1LWovbn7VfQkUOJy1zLoYQYY0JfxU O9EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=O2drNXyXMmMH0NXBz6jThSxqxTFQjLUiSHnpQbaTYxA=; b=xWMufDMzY7qa+5FIjkR/VJxQy63cRvNDaHlgCczemAbICO0gc1tmxp+hMeaHkN0EF8 RQ4JxHc9Om5kPU5uVaz1/ZloXhzLoZiP/vyHxrU/HpiKAk8jygxIn+zavZBqxztgSItc LXEgawjkFtLIGaxEC0c4MIqm4mUOCDHn+azDjzQAwOEczJI/pJYQQ/ZlbiugYQ+0CVCI vBeHjiI7554iChMHNr54mWODc9zmXsoiPIilOwtxy2aHixC3lWuEnKO4C4Z8RrKnKQZq 1RggQVEmdVVFZghYxiwdkNWXI3ZIcDHf5K97hOu1yeNniZDCJg4D9t0KxuxDI83VOMt7 DlBg== X-Gm-Message-State: ACgBeo2OVSMGnAsPZxOT8gwaC37FvWzKEbrCTE5HVMUyPL3X+PXT45pS tQutJNnn33olnVgR8NlaosXJX5R93Bpb7BuuQqoXwh8d X-Google-Smtp-Source: AA6agR5KAovXx7JSBL7w/AcA0SgbKSDFJ3jC3Ht+koHXS/iMy7EsNtJR3cAfhifM3sU/JdjjwfIuPuR0gsQZ+uREFTw= X-Received: by 2002:a17:902:cf0b:b0:171:270d:13ad with SMTP id i11-20020a170902cf0b00b00171270d13admr2381754plg.156.1660051378874; Tue, 09 Aug 2022 06:22:58 -0700 (PDT) In-Reply-To: <87fsi5zj9n.fsf@yahoo.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1030.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293306 Archived-At: --000000000000bf2cdd05e5ced4da Content-Type: text/plain; charset="UTF-8" On Tue, Aug 9, 2022, 8:36 AM Po Lu wrote: > Lynn Winebarger writes: > > > The second statement was comparing dumped versus undumped performance, > > whether native- or byte- compiled. This isn't a novel observation, > > but the dump is basically a one-shot mark-compact GC collection, and > > the mmap'ed pdump files would ideally be treated like the old > > generation of a generational collector, and so not traced in most (or > > all) collection cycles. This is (or should be) one benefit of pure > > space, although the requirement that it be read-only could be dropped > > as long as the write-barrier remains and is used to record any > > inter-generational pointers to a root set traced by the collector. > > This (very) minor benefit of pure space is already gone, since it is > unprotected and scanned normally for garbage collection in pdumper > builds. > I'm not sure you can conclude that the benefit would be minor when the non-collected space is a 184MB dump file instead of a fixed pure space that is 2 or 2.4MB as it is in the standard pdump. At least some vestiges of the write barrier appear to be in place during dump mode. I've had to make a lot of minor corrections of "defconst" keymaps to defvar, for example due to pure_write_error getting called. Whether that barrier is uniformly enforced or not is one of the reasons I suspect this quick hack would not be sufficient. Lynn --000000000000bf2cdd05e5ced4da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 9, 2022, 8:36 AM Po Lu <luangruo@yahoo.com&= gt; wrote:
Lynn Winebarger <owinebar@gmail.com> writes:

> The second statement was comparing dumped versus undumped performance,=
> whether native- or byte- compiled.=C2=A0 This isn't a novel observ= ation,
> but the dump is basically a one-shot mark-compact GC collection, and > the mmap'ed pdump files would ideally be treated like the old
> generation of a generational collector, and so not traced in most (or<= br> > all) collection cycles.=C2=A0 This is (or should be) one benefit of pu= re
> space, although the requirement that it be read-only could be dropped<= br> > as long as the write-barrier remains and is used to record any
> inter-generational pointers to a root set traced by the collector.

This (very) minor benefit of pure space is already gone, since it is
unprotected and scanned normally for garbage collection in pdumper
builds.


I'm not sure you can conclude that t= he benefit would be minor when the non-collected space is a 184MB dump file= instead of a fixed pure space that is 2 or 2.4MB as it is in the standard = pdump.
At least some vestiges of the write barrier a= ppear to be in place during dump mode.=C2=A0 I've had to make a lot of = minor corrections of "defconst" keymaps to defvar, for example du= e to pure_write_error getting called.=C2=A0 Whether that barrier is uniform= ly enforced or not is one of the reasons I suspect this quick hack would no= t be sufficient.

Lynn



--000000000000bf2cdd05e5ced4da--