Re: MPS: native comp

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Andrea Corallo <acorallo@gnu.org> writes:

>> The exact algorith MPS implements I don't know either. The docs include
>> some design documents, but I haven't read them all, and some I didn't
>> understgand because there was some context missing.
>>
>> A number of possible algorithms that could be used are described in the
>> literature, or one could glance at existing GCs for V8, for example.
>> Hard to read though, for me at least.
>
> I think is mandatory that at least some of us understand at least the
> high level mechanism of how MPS works otherwise before of later we will
> be beaten by it somehow.

Speaking for myself, I think I have some understanding.

Opa telling stories from the good old times again :-): Back in, I don't
remember exactly anymore, around the late 1890s ;-), not long after the
invention of sliced bread, I was implementing a GC for Emacs that was
very similar to MPS. Incremental, generational, mostly-copying,
barriers, but not concurrent. Concurrency was not that big a thing back
then ISTR. That was torpedoed hearing of the existemce of a software
patent for the mostly-copying algorithm, which I consider a trivial idea
:-(. (The patent has expired 10 years or so ago.)

All that's left of that is a C source file I posted to emacs-devel when
I left, which was also named igc.c, what a coincidence :-). I got that
some time ago from Stefan Monnier, who had kept a copy. I seem to have
lost it again. Not a loss.

Be that as it may. What I eanted to say is that I feel for myself I have
a good model of what MPS does in my head. I personally don't want to
dive into details of its code. It's a library for me. A good one I'd
say, and well documented. And if it does A or B is not important to me,
unless I land there in a debugger, and then I can see it.

I'm actually trying to spread some knowledge by talking/writing too much
sometimes. I know I'm in general not good at such things. And I'm of
course not an encyclopedia, or professor for garbage collection.

> My fear is that the GC requires the code is generated respecting some
> property way we might not respect.  Other issues might rise in the
> future if we don't understand all of this.

No special casing required for MPS. If it's valid in C, it's fine.

>> For me personally the most important aspect is interactive user
>> experience. Let's say complaints about GC pauses are not entirelly
>> unheard of ;-).
>
> I totally second your opinion on this.  OTOH given we (well you 😅) are
> doing the work now, is good we think about decision we are taking.

Don't forget Helmut and Eli! If they hadn't picked it up, it would
probably be dead already.

And I agree, with a twist perhaps. The whole experiment started with the
first commit in my local fork

  dbdc3a8745eab17c170be0bb27bd36515626f3b5
  Author:     Gerd Möllmann <gerd@gnu.org>
  AuthorDate: Tue Feb 20 06:42:49 2024 +0100
  Commit:     Gerd Möllmann <gerd@gnu.org>
  CommitDate: Tue Feb 20 06:42:49 2024 +0100

  Use MPS if available

  New configure option --with-mps=(yes,no,debug), on by default.
  If debug, use -lmps-debug, otherwise use -lmps.

  * configure.ac (LIBMPS, HAVE_MPS): New.
  * src/Makefile.in (LIBMPS): New.
  
So, we're _very early_, it's almost certain that things will turn out
not to work out, or experiments will be done how to do things best. And
so on.

> PS last week I failed compiling MPS :/ I hope I can retry in the future
> and have a look.

Maybe Helmut could help you? He's on Debian.