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: pdumper on Solaris 10 Date: Mon, 09 Dec 2024 16:21:02 +0000 Message-ID: <87bjxkhlpf.fsf@protonmail.com> References: <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> 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="456"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 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 17:39:28 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 1tKgn9-000AX9-A0 for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Dec 2024 17:39:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKgmN-0005j1-47; Mon, 09 Dec 2024 11:38:39 -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 1tKgVU-00070y-Sh for emacs-devel@gnu.org; Mon, 09 Dec 2024 11:21:12 -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 1tKgVQ-0002ev-Ly for emacs-devel@gnu.org; Mon, 09 Dec 2024 11:21:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733761266; x=1734020466; bh=NbEumjENpbIVbjMJLzRpavzXLJjolVEAdy9kvNyrshY=; 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=Mvk/X1PfBqGAdZqCEnGg3jbURacbj4HA8K/2JDhSnu/tMlXpKT3lbEI6mtC8wbDkE OuybW69l15u2PEgeyaZCqKOPfaACFNCSNYxj+U0kmd0mWfWUsA5FhTTzvL6vI6D+L3 UndeFFXhypEkxqxv75/2hSM3cHGQWGD3jGI+/TkSlEVOW2JhWY5HhtwZz1B6yw02ST qfHyfYbB95OUEq9Lqix1bTWqu2kn/9fYtt5/Birz8/xrJ9Dd49Qc34cIMG434DTMO/ YIAdxQgVh1tEMySzeykA9UAerU3Gn3pcWeQh1+YQpT7r/xYWk5YUiROrcE1fidqrUB hEVG8OOWp1SJg== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d9b9e1dc2fe23a630d9bb2997a9efb8914795825 Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 09 Dec 2024 11:38:37 -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:326254 Archived-At: "Stefan Kangas" writes: > 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 G= C >>> 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 Even if mps does land on master, the old GC will remain in place for a very long time, so I don't think we should declare the old GC a do-not-touch zone just yet. > making any changes here is basically wasted effort. Unless, of course, > the change would also simplify the mpc work (would it?). I believe it would, yes. > 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? > > Or am I misunderstanding how close we are to merging the mpc branch? My current understanding is that Eli expressed requirements for how things like the signalling issue should be fixed. While I have a solution that appears to work, it doesn't meet these requirements. >>> 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. I agree with Stefan here. Also, let's keep in mind that !USE_LSB_TAG in its original use case is currently broken, and has been for a long time. > 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. 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. I think that would be a good approach! I'd just like to add that stability concerns go both ways: it's a good reason to move the very few remaining users of !USE_LSB_TAG to use the same code (and experience the same problems) as all other users, rather than splitting what time we have for GC work between the two code paths. Pip