From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Merging scratch/no-purespace to remove unexec and purespace Date: Sun, 22 Dec 2024 14:12:36 +0000 Message-ID: <875xnbhkns.fsf@protonmail.com> References: <87zfku6ra9.fsf@gmail.com> <87seql7a3o.fsf@gmail.com> <87o71553yf.fsf@gmail.com> <87jzbsgefi.fsf@protonmail.com> <86seqf6f3n.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3157"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, eller.helmut@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 22 17:23:53 2024 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 1tPOkC-0000fp-TG for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Dec 2024 17:23:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPOiv-0007tc-0h; Sun, 22 Dec 2024 11:22:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPMhN-00040t-3P for emacs-devel@gnu.org; Sun, 22 Dec 2024 09:12:49 -0500 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPMhK-0003oH-74 for emacs-devel@gnu.org; Sun, 22 Dec 2024 09:12:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734876762; x=1735135962; bh=Z43aJgtLqEaW2DyXI+V80i1DJ6KfzMz8Ow/dqaRphEE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=WMsiYDvD1Od8QkXQ2b+AfsSRtW38QeJ7WKozrk2o0df7m3l7m23zrFvR13y75auTL 6oyO+v8oztDkQ3El2F8ZQAFz0tbHzNk6Z9ar0Py9ecD1l4+RB5wfDCu33PTIp/mAC3 ZSp8WZqrD7Nl8T7Yw+IwvXxTHBR/DAD8iOUEagUHd5dWB/Nmmhb9ATMquGUDdkjy0x HM9EBNCUTHFnbHgjxJKagnG+1hDFtFfXhMvdLIERQR4MfJujuHKEccbjX3iM9dzV0b 5UFmVjXnMDsHpe52ks4HNUC46cx9WK4C1MYpBWPILVM4hSFlUpmWwkmadF6Cmnh1jL RaNkKiY+LPXsQ== In-Reply-To: <86seqf6f3n.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7b41a83d4949df738e1fb32def2d4acb48e97631 Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.protonmail.ch 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 22 Dec 2024 11:22:31 -0500 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326863 Archived-At: "Eli Zaretskii" writes: >> Date: Sun, 22 Dec 2024 11:12:30 +0000 >> Cc: Helmut Eller , >> Stefan Monnier , emacs-devel@gnu.org >> From: Pip Cet via "Emacs development discussions." >> >> 1. choose a "tenured" set. I would hazard a guess that most objects in >> the pdumper file are usually not actually written to, ever, so maybe we >> could even get away with starting with a universally-filled "tenured" >> set. We could use, in essence, PGO to do so, by identifying call stacks >> for objects that are modified and excluding them from the "tenured" set >> based on the call stacks when the real Emacs is built. > > I don't think your guess is correct. My proposal was about hints (or guesses), not about hard promises. I see no reason to prefer the latter to the former: on the C code side of things, it causes complexity, because we need to deal with broken promises somehow (currently, we just crash, in some cases). I'm convinced it's worse for performance, because there are many mostly-immutable-but-someone-might objects which are still worth optimizing for. As for my guess, it is correct. I guessed that few objects are written to, so we can give a blanket *hint* that an object in the pdump is probably not going to be mutated. It's obviously true that some objects are, so inevitably some of the hints are going to be incorrect, but that's why they're just hints. > There are definitely objects in the pdumper file that are written to. Of course, but that wasn't the question. > Historically, the purecopy calls that created pure objects have their > legacy from the unexec era, when any Lisp object generated in temacs > was dumped into the emacs binary, and originally ended up in the BSS > section (and was shared between different emacs instances running on > the same system). It is thus possible that quite a few of pure > objects were there "by accident", and there's no need to keep them > from temacs stage. We already started to get rid of some of those, > but meanwhile did that only where pdumper caused trouble. IOW, we are > now in an interim state where some dumped objects don't need to be > dumped at all, but should be recreated anew when Emacs starts. > > So going by dumped objects is IMO following the wrong lead. I agree. > It would make sense to have a special API for defining objects that > need not be scanned by GC, in effect reintroducing pure space (but > with a different name and only for objects that are truly immutable). I disagree. I don't see the need for the "hard promise" character of that API. Hints seem to be sufficient, they cause much less trouble, and we can generate them (semi-)automatically because an incorrect hint would cost some performance but wouldn't crash Emacs. Most importantly, whether an object needs to be scanned by GC or not is very difficult to decide, and liable to change, and then we have to check all the API calls, and if we make a mistake it'll result in crashes. We know that would happen because we already did it, with purespace, and now master-branch Emacs is crashable. > However, it sounds like this adds back one reason why we wanted to get > rid of purespace: the tedious and error-prone job of identifying such > objects and marking them in the sources. That's why I think hints/guesses are the only option: then we can just ignore them, or lose some performance because of wrong hints, or correct them automatically, or whatever, without ever crashing Emacs. > OTOH, what other reliable ways do we have? Whether a given object is With hints, we don't need to be reliable, we just need an "oops, turns out not to be read-only" fire escape, which isn't that hard to do. > immutable is a programmer-level decision. I really don't see how this Why encourage programmers to even consider the question, though? I think of it as analogous to deciding the right size of a C integer: Lisp avoids forcing the programmer to make that decision, and it's a better language because of that. Guesses or hints are sufficient for performance, and they maintain the flexibility of simply mutating an object when we need to. They're also better for performance. (Char tables can be "sealed" so we don't have to scan the entire table, just the values used in it (and each value only needs to be scanned once). Mutation would mean unsealing them, and then we could re-seal them after another GC cycle or two without modfications. That's the kind of approach we should generalize, not "I promise not to modify this object".) > decision could be made automatically by Emacs. Hints (or guesses) can be done automatically. Hard promises, no. I'm comfortable giving up on hard promises for good. Pip