Re: pdumper on Solaris 10

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

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