emacs-devel
[Top][All Lists]
Advanced

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

Re: basic questions on MPS


From: Helmut Eller
Subject: Re: basic questions on MPS
Date: Fri, 26 Apr 2024 08:36:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On Fri, Apr 26 2024, Vibhav Pant wrote:

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

Thank you for the explanation.  It's interesting that they still have
acceptable performance with so many layers of abstraction.  And I guess
it's nice that everything is strongly typed instead of a bunch macros in
a header file.

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

I think this is a rather theoretical feature.  In practice, LLVM has the
same problem as GCC: they are designed for C/C++ and tracking pointers,
as needed for a precise GC, is just not part of the design.

Helmut



reply via email to

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