From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: pdumper on Solaris 10 Date: Sun, 8 Dec 2024 23:59:14 -0500 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13964"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Eli Zaretskii , Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 09 05:59:34 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 1tKVrq-0003UW-KZ for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Dec 2024 05:59:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKVrb-0004Xg-Jh; Sun, 08 Dec 2024 23:59:19 -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 1tKVra-0004UN-OF for emacs-devel@gnu.org; Sun, 08 Dec 2024 23:59:18 -0500 Original-Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tKVrZ-0003Ju-2F; Sun, 08 Dec 2024 23:59:18 -0500 Original-Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5cec9609303so4375269a12.1; Sun, 08 Dec 2024 20:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733720355; x=1734325155; darn=gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=HJ6cxQN+01RQljdzke3ozugrAjldUZ3m9x0Luh0s0KY=; b=g3l/0eRz2ZfsP/y0TL72NViLd4t6U1dA91fYcG3eM5/kjiJHrjVo7n3fw4BfQpQmr3 gq8RyUUTGvIs1GEWZURsCYnY6QRqqXs+x0xIRt5JJi4KFSxkV2Ay4uItDF4TmG3aL6wN XRCpaoAleqFBWWjt5A3SyegpB4BdiW+oNeNZ1W4CUwpOFdaGgIazDtVLBWS9RPQG6po6 dghnsRc5yMmf0sSECAmQc/dLcX4gYai1FEwQGOoi8kNODovuGpifr97oQ3+SvNddYBkM FrDY2DujDRgorC9Mrs3E2v9pfF9LVLpPViy3/9tzVpItPCet4hUuYN/bhXFBvCkO9Uq4 Py7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733720355; x=1734325155; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HJ6cxQN+01RQljdzke3ozugrAjldUZ3m9x0Luh0s0KY=; b=NVMU4o5ssr/Oad6eETST9Mn2JjaLJQoZJLwTGsIHqN/n5BEykYh3OJflTT6KphyTo+ rYyKgqObky5i2074q2DiJWQ6oFj9qT10QTSLo5BS24AWvkHS+AaIhjOIhKiuKglvdL5A TG0nm6kZaqCZtAwEnz4cVHbfT5w5TzOB356zo64CjKXX4LjWLdsybztkeUYEM9MAob0Y 0l1uc9dWLXDIs1xZF1hpsDjM33k+43G7BH3satfo6aKaTmk+Ouo5bE1MU/ROZ8db8vqO O1sBDDBpe9LpBu0G7dF87qWI29o93e4rVU/6LE0evpBNtMCkbFHTYlJ9StRSdjfE4IuM p6lA== X-Forwarded-Encrypted: i=1; AJvYcCWFRvKSI79qUy0Ia+VYhYNKtzfyJ+RVoh55tdpf305Cbr6YR90desWaqZRbfOUf60BK1vl+uN4hyoSEpA==@gnu.org X-Gm-Message-State: AOJu0YzwZL8So0AraCrJuArJnCdvYqTSj9H714C3Lt3zk5qgXWoOOd6B 1b90eZWqBM2qlf453kG64JyRJnBO4WfxjViFymfUr9c3jfzCV4Uxe9/hwjRnEOHXnUg7TZfciIH +yEsFVrlMErtEYGQdo0O+bgsHyjuAlg== X-Gm-Gg: ASbGncuBOu+OoEfzs8V+QNA0471G8F4O/4/SrCNilAUKN0p4StdesdyJbxpRHIiPa2X 1QSrFW32Ftfi1tXxRnpufMV8bbZfsHpCKEw== X-Google-Smtp-Source: AGHT+IFw4nBJqBqVoobgQ2OXQuGIziVFXKoZGSW0xGBDA469QW0uAkYU0Yc706NNRtdkEpQUsPJtcSwuXzzLgsdCFCI= X-Received: by 2002:a05:6402:915:b0:5d1:1024:97a0 with SMTP id 4fb4d7f45d1cf-5d3be66cad3mr11038325a12.6.1733720354614; Sun, 08 Dec 2024 20:59:14 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 8 Dec 2024 23:59:14 -0500 In-Reply-To: <8634iyf257.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=stefankangas@gmail.com; helo=mail-ed1-x536.google.com 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:326237 Archived-At: 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?). 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? >> 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. 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.