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 11:55:59 -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> <87bkstzg6e.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bda96005e5d0f812" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38593"; 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 17:58:31 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 1oLRcl-0009sW-02 for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 17:58:31 +0200 Original-Received: from localhost ([::1]:59352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLRcj-0008Hj-Tb for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 11:58:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLRaa-0005RM-RF for emacs-devel@gnu.org; Tue, 09 Aug 2022 11:56:16 -0400 Original-Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:40839) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLRaZ-0007HS-2H; Tue, 09 Aug 2022 11:56:16 -0400 Original-Received: by mail-pg1-x52b.google.com with SMTP id f11so11720246pgj.7; Tue, 09 Aug 2022 08:56:13 -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=znKeOHYK+L7JjKNhn//aUqq0guYoWtyKbf40kY79TUk=; b=hA7t/0DVEpECux32vv3gVly5lIZtV+yXJfxGyVTpd3Lz3xzlE2wlB1NJEWTIo+nACT OHhyTLEjfx97U5+Me1gbliafWj1tGP1glJxIdjyQzh02+vBnDgXq6w2HMrysn7zobfWA vcSbqUvw7fwLe4FhwXPCssICtoSfqh9gsV3h7te13aWCwBQmJnXVnIElnfq/n3zCh2Fh Y6GlIiFvCCsyRAJgS6bVF6G00eQr376Orl5YB4L9MbmVXOBcAX3TG7Zbv388ehRIXPw6 N7rfjbBi0O+UQIO5WRf0j+lh05qG+byx7mDr1B17BIptIOEPulco7HPsGg9EoKs8oTbW I/GQ== 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=znKeOHYK+L7JjKNhn//aUqq0guYoWtyKbf40kY79TUk=; b=f6acB5+6RzXp4wK+3u4p4FzJfOOc80bJojXbODdkrcxvBlennANO4ji83AE/4x/jaY M5nnPp4DXT59t6eMxCtLhG1VWixYEvAdInMmmjXrg8Aryka7HzF5uS6/+XCT9YLP6gR/ KjFGIe4D5VhswFd0CniKHfmSlZgluNMpDeBaHV7llL6cU5Enntvwe7tokA9K84fh1DTv VQJowrxFrMLMgKVH42gjwt5tz+4jKsB6BbTsFcuji6jLJ47zhoTAHRkMBPVSblMtYFtc uT8uZHHdFECkRkStPcOKSv6N0E1zb4VuA4vrQcmWgp0ZZlVzkiYy1h5b0mnmR3AG7aFB N8ig== X-Gm-Message-State: ACgBeo1+TmMIqm/9KGE8YqkR+DYg1WuqISdvQJ6ItBa/ZpitujzhWiVU qwBZRYxAjnz58yYxtlQizZ+8C1x38Cze0QErTq8= X-Google-Smtp-Source: AA6agR4HRpEH9wMtptf0vz6rCgeGfViEFq2C+ZYng+AZhzBHvzM6a5aVobXPx2B/NjnDLXBZUVuwvc2EsrUCMcccXt0= X-Received: by 2002:a63:2d1:0:b0:41d:9a9e:f2ae with SMTP id 200-20020a6302d1000000b0041d9a9ef2aemr6475432pgc.488.1660060572688; Tue, 09 Aug 2022 08:56:12 -0700 (PDT) In-Reply-To: <87bkstzg6e.fsf@yahoo.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::52b; envelope-from=owinebar@gmail.com; helo=mail-pg1-x52b.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:293315 Archived-At: --000000000000bda96005e5d0f812 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 9, 2022, 9:43 AM Po Lu wrote: > Lynn Winebarger writes: > > > 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. > > AFAIK we don't officially support any non-standard dump. > I'm not sure how that's relevant, but depending on what you mean by "support", it may not be totally accurate. Aside from providing the option of including site-load and site-init in the system build, there is the user-level function dump-emacs-portable. It's accurate to say the maintainers are not responsible for supporting every random set of libraries put together in a dump. But it's also fair to say that the impact of the system design on nonstandard user dumps is within the remit of the maintainers as a general matter. That said, the priority of such concerns is entirely up to the maintainers. > 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. > > I don't think it's very well enforced. For example, any C code that > calls XSETCAR without checking whether or not the object (i.e. the reuse > argument to Fmatch_end) is writable will result in the invariant being > broken. > True, but if all relevant mutators are effectively contained in lisp.h, the problem of imposing a write barrier would be effectively contained. Then it would just be a matter of determining if the cost of the write barrier being checked at every mutation is paid for by a perceivable reduction in gc-related pauses. But as I said, it's just a hack I'm tempted to try. I probably won't unless the gc pauses for this mega-dump build become intolerable. Lynn --000000000000bda96005e5d0f812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 9, 2022, 9:43 AM Po Lu <luangruo@yah= oo.com> wrote:
Lynn Winebarg= er <owinebar@gmail.com> writes:

> 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.

AFAIK we don't officially support any non-standard dump.

I'm not sur= e how that's relevant, but depending on what you mean by "support&= quot;, it may not be totally accurate.=C2=A0 Aside from providing the optio= n of including site-load and site-init in the system build, there is the us= er-level function=C2=A0dump-emacs-portable.=C2=A0 =C2=A0It's accurate t= o say the maintainers are not responsible for supporting every random set o= f libraries put together in a dump.=C2=A0 But it's also fair to say tha= t the impact of the system design on nonstandard user dumps is within the r= emit of the maintainers as a general matter.=C2=A0 That said, the priority = of such concerns is entirely up to the maintainers.
=

> At leas= t some vestiges of the write barrier appear to be in place
> during dump mode.=C2=A0 I've had to make a lot of minor correction= s of
> "defconst" keymaps to defvar, for example due to pure_write_= error
> getting called.=C2=A0 Whether that barrier is uniformly enforced or no= t is
> one of the reasons I suspect this quick hack would not be sufficient.<= br>
I don't think it's very well enforced.=C2=A0 For example, any C cod= e that
calls XSETCAR without checking whether or not the object (i.e. the reuse argument to Fmatch_end) is writable will result in the invariant being
broken.

True, but if all relevant mutators are effectively contained in lisp= .h, the problem of imposing a write barrier would be effectively contained.= =C2=A0 Then it would just be a matter of determining if the cost of the wri= te barrier being checked at every mutation is paid for by a perceivable red= uction in gc-related pauses.
But as I said, it's= just a hack I'm tempted to try.=C2=A0 I probably won't unless the = gc pauses for this mega-dump build become intolerable.

Lynn





--000000000000bda96005e5d0f812--