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: Mon, 9 Dec 2024 19:09:59 -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> <8634iwex8q.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="10438"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 10 01:10:57 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 1tKnq5-0002WD-LN for ged-emacs-devel@m.gmane-mx.org; Tue, 10 Dec 2024 01:10:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKnpM-0003fZ-8R; Mon, 09 Dec 2024 19:10:12 -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 1tKnpF-0003GF-U2 for emacs-devel@gnu.org; Mon, 09 Dec 2024 19:10:06 -0500 Original-Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tKnpD-0002AV-OG; Mon, 09 Dec 2024 19:10:05 -0500 Original-Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5d3e6f6cf69so3698803a12.1; Mon, 09 Dec 2024 16:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733789400; x=1734394200; 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=4o5eRhyisifLB77BQ/Xc2W3BG/RxUOM+l0+amoYtOw8=; b=SxtQOG9NqjrkSDNnA51K8UfP1pczVepvO9ic6t/qw0eAD7rv5rdlr2+b4OZ/LZ/bU1 wwske/50IPVgE2iu24atlylxix+W7DhnaVZ7l9jTHJjHPMl0cnxsR2WXITzoM8AhPRzZ M0C70xqW2IjUSMqxcjmrB2kqO8b9tyOBgQKoKPuGbRWUAVUpdRe8sgEcVRKiDKBVf5vr iy4ebxqRW8EFjT/IxipD7w++/mlIj+IHUDmkmhTMY1UktLA4TtcnJCdtQbTbFDkLmu01 sBp69r1kf/sYQQjnh8H2ZO4CSZO081YInZRvY33A5JKtm0qLmAO78agT7+HGljwhVC1D LQuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733789400; x=1734394200; 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=4o5eRhyisifLB77BQ/Xc2W3BG/RxUOM+l0+amoYtOw8=; b=KbQ5qC64a7soKQRUaVXdGvc8MIfW94HnY30z4bcLyKnH1Dh9vx9M7IVgCU+CKsSn7W YDe4eKeg9pmQMW2EqAeikXvhEqlFiSz83ZXhqcLCbnWQQCgLEVVh9JqvpvyfICIDQl0l 1FBzLrMeBY2/gEY9bDuAdl0XDyFqvTR8Sfny8eXdQbiUvNgITOmaL+qmdmPbiR/V9zPa TtlP/wOctHaXt+jj1a18OzIPBMUUUGcX1Crl745TrgNnh3JkfJS8rj5YlP2dIjmtWB56 bcOwFsONwhMFn6652uC6Y68ZngJNTKs4SFHBvazNFPEwSAlpUo5D8rgKqUU226+iJ+MC s1bw== X-Forwarded-Encrypted: i=1; AJvYcCWOeCp1tKqcRs6tvRUGUDsyvVjfb5h0rnmkMI8M6PkhFYcKo2Vs9oHbbZhC8Nl4IC0z+tprrWuPgmPcJg==@gnu.org X-Gm-Message-State: AOJu0Yxh2vEkyptYr4SZ3ZZOIlQVP/DZCJOFXTLPbjmm532ZjKka8aop HDu0cjN4NEP5ForrjiSmnYR00GF0v/APeKZScjSAs9q96/qYqjb3fClq62ugOCtYO/XGWhWVqi1 rPOiURZ8mr2zs6TNWMkORqN2hqB30qg== X-Gm-Gg: ASbGncsyqSx2rqXV55KaRzOPgc5EuAUrk/KmWbStRudd0zmawQu5b1er1u4jlmmlYC7 tOo8M4yH1xQFqtbam6q7jh/G5VQiKGCl1XZ5XVg== X-Google-Smtp-Source: AGHT+IGi+l7tW1ndWGwH5tXyqPbZc1I2JZKb6FTPt3yVa7DMOibgXc9xg6grqPYxD8q4n9BAi2ZERB48zUJpwW7Az6E= X-Received: by 2002:a05:6402:360f:b0:5d0:e826:f0ec with SMTP id 4fb4d7f45d1cf-5d3be6bd823mr14477800a12.4.1733789399734; Mon, 09 Dec 2024 16:09:59 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Dec 2024 19:09:59 -0500 In-Reply-To: <8634iwex8q.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::52d; envelope-from=stefankangas@gmail.com; helo=mail-ed1-x52d.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:326263 Archived-At: Eli Zaretskii writes: >> From: Stefan Kangas >> Date: Sun, 8 Dec 2024 23:59:14 -0500 >> Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org >> >> 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. I thought that WIDE_EMACS_INT will remain supported in non-MPS (i.e. "old GC") builds even after the igc merge? Am I mistaken? >> 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. I agree that it's not a major issue, indeed. You don't need to look at this unless you want to understand how we do GC tagging in detail. OTOH, complexity almost always presents itself in small increments that individually don't look like much. It's only with the combined effect of many such small increments that they become a concern; hence the desire to take similarly small steps towards removing complexity. >> 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. That's why I proposed disabling it on master tentatively, with the option to revert the change if we don't like it. Setting a flag back to 0 is easy enough. But making the experiment I proposed might also demonstrate that we're fine, after all. OTOH, if we don't make the experiment, we have less data on which to base our decision. >> 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. Is your thinking here that we could merge MPS, wait, and then when it comes time to remove the old GC, we will get to drop !USE_LSB_TAG for free? If yes, couldn't that leave us waiting for a very long time indeed? Or are you saying something else?