emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: native comp


From: Andrea Corallo
Subject: Re: MPS: native comp
Date: Tue, 30 Apr 2024 08:59:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> 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 don't have any doubt you have knowledge of GCs (I do as well to a
certain degree) or how the MPS interface works.  But still my basic
question is unanswered and we don't know how MPS can work reliably in a
parallel fashion moving objects.

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

Maybe depending on how the C is written (keeps local non volatile
references to objects) the collector can move objs or not in parallel?

Or maybe the moving part never happen in a parallel fashion? 🤷

I'm saying we'll have to understand all of this (willing or not).

Thanks

  Andrea



reply via email to

[Prev in Thread] Current Thread [Next in Thread]