Re: pdumper on Solaris 10

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 8 Dec 2024 23:59:14 -0500
> Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Sun, 08 Dec 2024 17:37:50 +0000
> >> From: Pip Cet <pipcet@protonmail.com>
> >> Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org
> >>
> >> "Eli Zaretskii" <eliz@gnu.org> 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.