Re: basic questions on MPS

[vibhavp]

On Fri, 2024-04-26 at 08:36 +0200, Helmut Eller wrote:
> 
> 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.
> 
> 
Indeed, which is why the MMTk documentation recommends that final
production builds be compiled with LTO enabled. If everything's getting
built using LLVM, then cross-language LTO (Rust <-> C) also gets
utilized, ideally.

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

Pointer tracking in LLVM is still WIP from what I understand, but the
documentation for statepoint tracking intrinsics
(https://llvm.org/docs/Statepoints.html) does claim that "these
mechanisms are well proven with commercial java implementation with a
fully relocating collector having shipped using them." (I believe
they're referring to Azul).

Vibhav