Re: pdumper on Solaris 10

[Pip Cet]

On Tuesday, December 10th, 2024 at 12:59, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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)?

It's !USE_LSB_TAG that's incompatible with MPS, not WIDE_EMACS_INT per se. I 
don't think anyone suggested that there is a fundamental problem if we force 
USE_LSB_TAG to 1 and enable WIDE_EMACS_INT.

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

!USE_LSB_TAG && !WIDE_EMACS_INT stack scanning is broken (but doesn't currently 
happen on actual machines)
USE_LSB_TAG && WIDE_EMACS_INT (currently impossible, but trivial to enable) 
stack scanning works
USE_LSB_TAG && !WIDE_EMACS_INT stack scanning works (this is the usual case)
!USE_LSB_TAG && WIDE_EMACS_INT scack scanning works (this is Eli's situation)

So following Stefan's suggestion would fix the broken case. I've already 
reported that I tested this with the patch I posted and it appears to work just 
fine, with or without MPS.

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

The old !USE_LSB_TAG code, which is broken, interferes with GC development, 
both MPS and non-MPS.

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

Given how many GC developers we have already "lost", simplifying the GC code 
even a little so people can work with it is worth it, IMHO. And encouraging 
someone to invest resources into fixing a code path that will never again be 
used is a much greater mistake.

Pip