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: Wed, 18 Dec 2024 13:35:36 +0000 Message-ID: <87o7199ksn.fsf@protonmail.com> References: <87zfku6ra9.fsf@gmail.com> <87ed2579eg.fsf@gmail.com> 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="4516"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , Stefan Monnier , emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 18 15:25:18 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 1tNuzF-0000zk-Rs for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Dec 2024 15:25:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNuyW-0006eb-T9; Wed, 18 Dec 2024 09:24:32 -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 1tNuDM-0004IT-Cx for emacs-devel@gnu.org; Wed, 18 Dec 2024 08:35:51 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNuDK-0003Ma-3f for emacs-devel@gnu.org; Wed, 18 Dec 2024 08:35:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734528941; x=1734788141; bh=yuBDuG3cP6U+M2ertnylqguOx882BKRAXee1qmCg7IE=; 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=KODNhK7imLwbD9YCex9wsEQGUnMF/r/sHlA/pwqfmCpfsYBN4eTFZV+O0/6ZsXFyM Umso84h1i7kjUB/qQ8LEI2S0cZw/aJLdZSMNmb+gK9jA4bPEmvy/KNwbVTph0Gwk1K mB3JgPY1sNKqk0/mUf0K576qRryMi26kFCRYOJnA97D5u+vNKknm6mzCB6ZyYeI7sC GBBiGFNff2NT5vX/dLev5S91rINv9eJKY8wg0BnaXhRQO5APGbDhx9n61N8DjF2cxh Q3hZDbWGGZ0JZHzMnQX+1uALEBru78oY0kGDSuEFz9CIUo+tGFVtjUE5ocYbcLclP+ 75jpJe99Yi+6Q== In-Reply-To: <87ed2579eg.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 124c42c31de325f10eafc4eef7007d4809304e84 Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 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_MSPIKE_H2=-1.116, 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: Wed, 18 Dec 2024 09:24:29 -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:326656 Archived-At: "Helmut Eller" writes: > On Tue, Dec 17 2024, Stefan Kangas wrote: > >> Stefan Monnier writes: > [...] >>> That's because the pdump already fails to take advantage of the >>> purespace (i.e. the GC traces through the purespace like the rest of >>> the heap). >> >> I'll note that the best solution to that is to have a generational GC >> instead. Simple, right? > > A generational GC is definitely simpler. Whether it's the "best" > solution is not so clear: A copying GC, like MPS, still needs to trace > and copy pure objects whenever the oldest generation is in the condemned > set. > Moving pure objects to a non-moving pool might be better. I think we should rephrase that without presupposing the existence of "pure" objects: Hinting to MPS that an object is expected to be immutable and have a very long lifetime may have advantages, and that's a potential reason for introducing (and maintaining) a hinting mechanism. On the other hand, it's very common for objects to have those properties without us knowing in advance that they will, so it's important MPS works well in the absence of such hints. >> It's not entirely unrelated though: among other things, one reason why >> merging this would be good is that it would reportedly simplify the work >> on the igc branch. And indeed any GC-related work now or in future. > > Objects in purespace are immutable and immortal. That's potentially > useful information for the GC. I may be misunderstanding what you mean by "immutable", but the most important property "pure" objects had was that they only referenced other pure objects or static objects, so GC didn't need to look at them (but, IIUC, this optimization never worked in pdumper builds). This required us to make such objects read-only (which caused problems) and immortal. Immortality was an undesirable, but necessary, side effect of the "pure" optimization, not a feature. IMHO, so was immutability, but some people consider it a feature not to be able to modify certain objects. For example, on the no-purespace branch, you can execute (aset (symbol-name nil) 0 ?N) and rename nil to Nil, which will make the rest of your Emacs session unusable. On master, this code should (and did at one point, IIRC) throw a CHECK_IMPURE exception. Right now, it segfaults, which demonstrates that the current purespace code has suffered from some bit rot and removing purespace will fix some bugs for that reason alone. So the two major features of pure space are broken right now. Fixing that is an option, and it's the only way we'd ever see a fair comparison of purespace and no-purespace performance, but I hope it's not going to happen. So what's left is a weak hint to the GC that this object is likely to remain reachable, and not to be modified, but for MPS to set up a "pure" space of such objects based on this hint seems to me to be an unrealistic expectation. > Removing purespace also removes that information. Removing purespace does leave us with very few read-only objects. We can consider introducing a useful set of read-only objects (and agree on what that even means) after purespace is removed. However, I would be surprised if the lost information about whether an object used to be pure turns out to be very useful. > Of course, if the pdumper already throws away this > information, then purespace just adds useless complexity. I believe that's the case. In fact, once we remove purespace, we can look at improving how pdumper dumps are handled during GC. Maybe we can make it so the pdumper dump looks even more like an ordinary MPS segment in memory, and then we don't need to treat pdumper objects specially. Pip