Re: basic questions on MPS

[Gerd Möllmann]

Vibhav Pant <vibhavp@gmail.com> writes:

> On Thu, Apr 25, 2024 at 11:23 PM Helmut Eller <eller.helmut@gmail.com> wrote:
>>
>> I'd also have some MPS related questions.  Just curiosity.
>>
>> 1) Does somebody have experience with this MMTK [https://www.mmtk.io/]?
>> How does it compare to MPS?
>>
>
> From my understanding, MMTk is a *framework* for writing a memory
> manager + an API for allocating and working with allocated memory. A
> language runtime being "ported" to MMTk seems to involve these two
> things:
> * The language's VM and memory management model needs to be thoroughly
> known to MMTk. It should know how objects addresses in the language
> look like, where and how their metadata gets stored and loaded, how
> copy semantics are implemented, etc
> (https://docs.rs/mmtk/latest/mmtk/vm/trait.VMBinding.html).
> * The language runtime calls *into* MMTk's language-agnostic memory
> management API for allocating memory, setting metadata, attach
> finalizers, etc. Even stuff like pointer arithmetic needs to be done
> through MMTk, as the language runtime code cannot make any assumptions
> about the memory model.

That sounds expensive, to say the least, both performance-wise and
implementation effort involved to make Emacs use the MMTk API. If it
could technically be done (Rust <-> C?).

> Once that's done, a program can choose which GC algorithm it would
> like to use during runtime
> (https://docs.mmtk.io/api/mmtk/util/options/enum.PlanSelector.html).
> MMTk/mmtk-core by itself does not "support" any languages, as one goal
> of the project seems to be to provide a way to write garbage
> collection algorithms for an abstract virtual machine.

Thanks for the overview!

> Perhaps not the same thing, but a similar idea is LLVM's support for
> GC (https://llvm.org/docs/GarbageCollection.html), as LLVM IR code
> generated by a compiler in such a case uses special instrinsics for
> fiddling with pointer metadata, declaring write and load barriers,
> etc, with the basic idea being that LLVM knows everything about
> managed objects in the language runtime. You can then write a garbage
> collector as an LLVM plugin, which theoretically can be loaded at
> runtime.

Yes, I've seen that too. Very interesting, but I guess it's out of reach
for GNU.