Re: pdumper on Solaris 10

[Pip Cet]

On Tuesday, December 10th, 2024 at 13:39, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Eli Zaretskii eliz@gnu.org writes:
> > Maybe so, but why is such a long wait a problem? GC works, and
> > works well.
> 
> Working on certain projects with lsp-mode is a miserable experience due
> to all the random pauses.

To be fair, part of that may be the gap buffer problem rather than GC.

> My perception of the past week or two using igc is that those pauses are
> much less jarring, if perceptible at all. I need more time to make a
> definitive judgment, though.

If you do, and it's negative, please take into account that MPS offers many 
tunable parameters, and hasn't been fine-tuned for Emacs yet. Even if the 
current scratch/igc branch isn't satisfactory by itself, it's very likely it 
can be improved by changing some numbers.

> But the "stop the world" mode of GC operation makes user experience
> quite worse even if the total time to perform a task is smaller.

Of course, these problems are largely fixable, and have been fixed, by such 
approaches as the fork()-based GC I wrote, which Eli vetoed (I believe the same 
applies to moving the GC mark bits to their own memory regions, which would 
have allowed us to interrupt GC on user input). The "don't touch the GC" edict 
has done a great deal of harm to Emacs; this is relevant because we're now 
discussing a simplification of the GC code which would help MPS, but is being 
vetoed (again), while putting effort into making our current code even more 
complicated by including an impossible code path is being encouraged.

So, no, the current GC doesn't work well, it does cause problems, its code is 
overly complicated, and simplifications would make switching to MPS a lot 
easier. All is not well in GC land.

Put drastically, if MPS fails to land, the most likely reason is the 
capriciously-applied "do not touch the GC" rule.

Pip