From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch) Date: Tue, 23 Jul 2019 17:56:14 +0300 Message-ID: <83imrspzox.fsf@gnu.org> References: <20190721193221.1964.53182@vcs0.savannah.gnu.org> <20190721193222.8C19E20BE2@vcs0.savannah.gnu.org> <83blxmqfkq.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="174824"; mail-complaints-to="usenet@blaine.gmane.org" Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 23 16:56:35 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hpwDS-000jNM-Sl for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2019 16:56:35 +0200 Original-Received: from localhost ([::1]:44588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpwDR-0006Ag-Ow for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2019 10:56:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37420) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpwDJ-0006AI-VM for emacs-devel@gnu.org; Tue, 23 Jul 2019 10:56:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hpwDJ-0000Zu-IA; Tue, 23 Jul 2019 10:56:25 -0400 Original-Received: from [176.228.60.248] (port=3452 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hpwDI-0003PI-Cn; Tue, 23 Jul 2019 10:56:24 -0400 In-reply-to: (message from Pip Cet on Mon, 22 Jul 2019 19:05:43 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238843 Archived-At: > From: Pip Cet > Date: Mon, 22 Jul 2019 19:05:43 +0000 > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > > > The same goes for removing the pure space, IMO: another core feature > > whose existence and traits many parts of Emacs came to take for > > granted. > > Let's not remove pure space for Emacs 27. > > (The traits of pure space changed significantly, with the introduction > of pdumper: CHECK_IMPURE is now a nop rather than a valuable debugging > aid, and PURE_P is always false. That is something we should mention > somewhere, along with all the good NEWS, because it will make Emacs 27 > harder to maintain. But that's all we should do, I think, document > the odd state we're in now and resolve to change it when it is more > appropriate to do so.) > > > I'm all for improving GC and simplifying our memory management, but > > please keep the above in your minds when you play with this stuff. > > Especially as, judging by the changes you are making, the details and > > indeed some of the aspects of the idea of the changes, are not yet > > sufficiently clear/finalized. > > I'm forced to agree, as far as my ideas are concerned. > > Eager rehashing of hash tables: needs to be timed precisely right for > user-defined dumped hash tables to work, as Paul apparently wants them > to, and my current proposal isn't (but let's fix Fclrhash to work on > non-rehashed hash tables). > > Hash tables without internal free vectors: change the interpretation > of the hash table API (:size has to be reinterpreted to remain > meaningful), and some trade-offs about when to use hash tables. > > Four tag bits for "annotated" (e.g., immutable) objects: very far from > ready, and problematic on 32-bit machines (perhaps this is no longer a > concern for Emacs 28...) > > Turning pseudovectors into their own tag type, as miscellaneous > objects: not convinced it's worth the change, yet. We can still have these on a branch, or on several branches. > > An alternative would be to make these changes on a branch, and merge > > that branch when it is sufficiently stable and mature. Please > > consider this possibility. After all, these two issues are not > > terribly urgent to fix (unlike, say, the unexec thingy). > > I'm not quite sure which "unexec thingy" you're referring to. A.k.a. "pdumper".