Re: pdumper on Solaris 10

[Stefan Kangas <stefankangas@gmail.com>]

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?).

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.