Re: pdumper on Solaris 10

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

"Stefan Kangas" <stefankangas@gmail.com> writes:
> 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

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