Re: pdumper on Solaris 10

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 9 Dec 2024 19:09:59 -0500
> Cc: pipcet@protonmail.com, luangruo@yahoo.com, ali_gnu2@emvision.com, 
>       emacs-devel@gnu.org
> 
> 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?

Probably, but who will want to give up igc to get back WIDE_EMACS_INT
(if indeed they are incompatible, which seems to be in disagreement)?
I most probably won't.

> OTOH, complexity almost always presents itself in small increments that
> individually don't look like much.

But here we have only a handful of increments, so the sum is also
minuscule.

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

I think we already know that we are "not fine"?  Didn't someone say
that stack scanning is broken?

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

Maybe so, but why is such a long wait a problem?  GC _works_, and
works well.  There are no pressing problems there, and we've lived
with it for many years virtually without changes.  What's the urge to
make modifications there now, especially when there are chances we
will be dropping this GC at some point?

IMO, our main task here is to develop the application levels of Emacs,
and infrastructure needed to enable such developments.  We should only
invest efforts in stuff like GC and other basics if we see significant
issues, or could envision significant performance gains.  There are no
such issues or gains here, AFAIU.  So diverting our humble resources
to such jobs is a mistake, IMO.