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: pdumper on Solaris 10 Date: Mon, 09 Dec 2024 16:39:49 +0200 Message-ID: <8634iwex8q.fsf@gnu.org> References: <878qwuitbu.fsf@yahoo.com> <87jzcajrnz.fsf@protonmail.com> <86o71mfhox.fsf@gnu.org> <87frmyjn9j.fsf@protonmail.com> <86ldwqfcqv.fsf@gnu.org> <87a5d6jgim.fsf@protonmail.com> <86a5d6f7bn.fsf@gnu.org> <871pyijctd.fsf@protonmail.com> <8634iyf257.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18810"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 09 15:40:56 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 1tKewR-0004gz-O4 for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Dec 2024 15:40:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKevW-0005nD-H2; Mon, 09 Dec 2024 09:39:59 -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 1tKevS-0005mr-4T for emacs-devel@gnu.org; Mon, 09 Dec 2024 09:39:54 -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 1tKevR-0007Co-FU; Mon, 09 Dec 2024 09:39:53 -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=kOLwtjPLuoqTdLTX5+zckeWVCQqd8H2f8fKJvnjwVCI=; b=NB43S3W7Svpk mlnqtjpehQtqiprbEJ5Xyd1FvZq0XCL43lP8fhEA0zkTl+1UnlGJ2/8p2OFovRsXYbr+IetXNt8Ic EngLnyghmLQqVQw0X6yK8+JGAUraARk85HIu9/y078VRMJ9v3bi10u9u6ThaDlSiAYh35H9vFUSiK RQxXM0JhyS2CJG9SoTI+ysTFXiMy7lfwD2j8SGzyoe1nufDmSEJfXvyaS4QqkamOQMUaOfv4gzLX3 a7xf5nAtdM6ggZZ7GKxsJ9pYj5EyjCxiKGg6e7rl898jyMuDCUKHZ0c5KAyyDzhY6zMJG51oxFi1B aO8ho7KQ/luOJko+aUKdVA==; In-Reply-To: (message from Stefan Kangas on Sun, 8 Dec 2024 23:59:14 -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:326245 Archived-At: > From: Stefan Kangas > Date: Sun, 8 Dec 2024 23:59:14 -0500 > Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org > > Eli Zaretskii writes: > > >> Date: Sun, 08 Dec 2024 17:37:50 +0000 > >> From: Pip Cet > >> Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org > >> > >> "Eli Zaretskii" writes: > >> > >> >> So let's remove it, and switch WIDE_EMACS_INT builds to USE_LSB? > >> > > >> > That'd be a waste of effort. > >> > >> It'd be a good investment of effort today, in exchange for making the GC > >> code significantly easier to understand and maintain in the future. It > >> would certainly not be without its benefits, so calling it a "waste of > >> effort" is unfair. > > > > I disagree. We've lived with this GC code for a long time, and I > > don't see any complications due to !USE_LSB. And if we are going to > > switch to igc at some point, investment in GC is even less sensible. > > Assuming that we are 100% sure that mpc will land, then I can agree that > making any changes here is basically wasted effort. Unless, of course, > the change would also simplify the mpc work (would it?). The igc branch already dropped WIDE_EMACS_INT support, so it only supports USE_LSB anyway. > On the other hand, IIUC, we have some way to go with making the merging > of the mpc branch a guarantee. While I'm an enthusiastic supporter of > the great work that's being done on the mpc branch, isn't hedging our > bets prudent until that work is done? >From where I stand, what's left to do on the branch is stability: using the branch, reporting bugs, and fixing them, especially on some rarer platforms (*BSD, for example). Plus some decisions: do we fork MPS or not, for example. So it isn't such a distant future. > Or am I misunderstanding how close we are to merging the mpc branch? Possibly. > >> If performance and wasted memory aren't issues, then it's a tradeoff > >> between leaving old code untouched and simplifying it to enable future > >> development. > > > > The existing code doesn't preclude nor interfere with future > > development. So yes, leaving working code untouched is the preference > > here. > > Based on my limited mucking around in the GC, it does interfere somewhat > because you do need to understand both configurations, at least on a > high level, and once you do you need to mentally filter that stuff out > when reading the code. So I think I'd appreciate the simplification, at > least. The simplification is minuscule at best. We need to mask some bits, either at the LSB end or at MSB end, that's all the difference. And we have macros that hide the differences from most levels. And remember that the original scheme of tagging in Emacs was !USE_LSB, so some veterans might even prefer it. > If the only known drawbacks are stability concerns, we could also > consider an intermediate step along these lines: > > Leave the USE_LSB_TAG code as is, but set it to 1 in all configurations > on master. That would put the WIDE_EMACS_INT configuration at risk, since that configuration will need changes. > See what issues crop up, if any. If anything does come up, > ask Pip Cet to fix it (he volunteered, IIUC), and if things are starting > to look too hairy, revert EMACS_WIDE_INT back to !USE_LSB_TAG. If > nothing too bad comes up, we can then consider removing the associated > code in Emacs 32. My point is that all of that could be avoided entirely, given some development decisions which basically drop !USE_LSB_TAG configurations.