Re: Merging MPS a.k.a. scratch/igc, yet again

[Pip Cet]

On Tuesday, December 10th, 2024 at 15:37, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Pip Cet pipcet@protonmail.com writes:
> 
> > > * MPS does a performance-critical job. Using it as a shared object might
> > > incur in a performance penalty. Having it in source form alongside the
> > > Emacs sources will result in opportunities for optimizations (LTO,
> > > PGO, ...) that may bring better performance.
> > 
> > ...and more problems. MPS has made the decision not to work with gcc
> > -O3, only with -O2 or less, and LTO in particular is something MPS
> > cannot reliably support, IIUC.
> 
> That sounds worrysome. If I understand the implications of what you
> wrote, MPS basically depends on what the specifics of what gcc does. But

No compiler can perform cross-object linking without LTO, so we're safe there.

> gcc can do something else on future versions... not to mention what
> happens if the user wants to use other compilers.

GC in general depends a lot on the compiler (and the programmer) not 
misbehaving. It is perfectly legal for a C compiler to scramble a pointer in a 
register, for example, but all conservative stack marking GC approaches will 
fail to recognize such a scrambled pointer and crash.

> Can you point me to a description of how MPS is related to compiler
> optimizations and specifically to LTO?

I'll have a look.  IIRC, setjmp() and the "void *top_of_stack = &top_of_stack" 
trick failed to properly detect all registers when the entry point was being 
inlined across objects, and Ravenbrook decided against moving to assembly code 
for those entry points.

Of course there's also the scrambled frame pointer problem, but that's about 
what the client code does, not just about the MPS code.

> > > * MPS does a correctness-critical job. Depending on multiple external
> > > sources for such core component is a recipe for problems (future
> > > changes by the MPS maintainers, patching by packagers, buggy
> > > compilers, etc.) We need to keep a close watch on what MPS incarnation
> > > we use. Better yet, total control.
> > 
> > I think the correctness argument goes both ways: shared linking means
> > bugs may be fixed for you automatically, as is routinely the case with
> > libc.
> 
> libc is a central piece of any GNU/Linux distribution and therefore much
> cared by the packagers. MPS not so. Fixes on minor packages like MPS can
> take years to propagate through the distro universe, if at all.

Very good point, thank you.

> > > For those reasons, incorporating MPS into the Emacs sources is the right
> > > thing to do.
> > 
> > I don't think that's an option, because Emacs should remain capable of
> > switching to GPLv4 if and when that is released, and we don't know
> > whether the MPS license is compatible with such a future document.
> 
> Yeah, the licensing point is what I was too afraid to mention :-)

Don't get me wrong: if Ravenbrook were to assign copyright to the FSF, 
including it in Emacs would be TRT, but that's unlikely to happen.

Pip