From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Merging scratch/no-purespace to remove unexec and purespace Date: Sun, 22 Dec 2024 15:07:24 +0200 Message-ID: <86seqf6f3n.fsf@gnu.org> References: <87zfku6ra9.fsf@gmail.com> <87seql7a3o.fsf@gmail.com> <87o71553yf.fsf@gmail.com> <87jzbsgefi.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27881"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, eller.helmut@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 22 14:09:17 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 1tPLhs-0006hG-H9 for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Dec 2024 14:09:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPLgD-0008A9-CP; Sun, 22 Dec 2024 08:07:34 -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 1tPLg9-0007f0-IM for emacs-devel@gnu.org; Sun, 22 Dec 2024 08:07:29 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPLg7-0002EI-A8; Sun, 22 Dec 2024 08:07:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=o5m2gsFj9dLAyHNXEmk93gFhTN13QJ+2m+Bh9Wydyz4=; b=aDezCKrrwKH5 V0dQklQJ+yMs6eTUpx+gI86hcc6BK+0Pz1rvfBjgBBpMPVsuyNej+hov6S2dTqAIyKeyJAPXE3BEy +QdR+TYgpqjC0C2MsYH7nKn91UIc0OYaKpde/mbfnWjSg7E7G9tJSuCsohEhfzx/7kmFAK/ABR4ax 2xA2U0ySsoNE/vFI8CZhdewAH0RONBNy0Fad0lYs0Zh5UEv1NXunWKZ1NfQf5mJ8vovb92QUk0Tgt ViDbZ1miLOEEAfgCWhS3LsOpsZBypIwoJoPYwjl0rAOyTuP13vMLh4cPs69V4qBZQv9tPM53gfUS8 f8OpF4NPyTMWK3xxzuqtpw==; In-Reply-To: <87jzbsgefi.fsf@protonmail.com> (emacs-devel@gnu.org) 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:326852 Archived-At: > 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. There are definitely objects in the pdumper file that are written to. Example: the *scratch* buffer. 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. 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). 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. OTOH, what other reliable ways do we have? Whether a given object is immutable is a programmer-level decision. I really don't see how this decision could be made automatically by Emacs.