mps VS datatype99

I have a library which has an extremely slow free, around 2m for large files, because of unnaturally scattered allocation patterns, but this old conservative GC didn't help at all. It was about 40% slower with libgc. mimalloc was a bit better. Best would be a properly fast GC, like mps https://github.com/Ravenbrook/mps, but this would be too much work.

The first thing you should look at is MPS (see https://github.com/Ravenbrook/mps and https://www.ravenbrook.com/project/mps/). It's open source, professionally maintained and very powerful, and it was used e.g. in Dylan and LispWorks.

I wonder how the MMTK compares to the venerable Ravenbrook MPS https://www.ravenbrook.com/project/mps/ which originated in Harlequin’s programming language implementations, particularly Dylan.

I am trying to implement garbage collection for my language because I want memory management for arrays/lists and strings. I am looking through LLVM's garbage collection page but the documentation isn't great. Are there any other resources that offer more concrete steps to implement garbage collection? Would it be wise to circumvent LLVM all together for garbage collection and only use something like the Memory Pool System? Thanks!

This post seems related to the authors of MPS (1) that seems to be a general garbage-collector to use with various languages.

Many GC'd languages really didn't bother with stack-allocating variable-size entities, and regardless of if they did then _precicely_ scanning the stack would be complicated without compiler help.

If the compiler doesn't leave any info to the GC, then it can't know if it's scanning a pointer or a float and if your GC strategy relies on compacting memory (ie moving objects) then trying to guess between a float or a pointer can become fatal.

(1) https://github.com/Ravenbrook/mps

Sum types and pattern matching have already been hacked together in a preprocessor macro in C; see https://github.com/Hirrolot/datatype99.

It does not. There are people who have implemented such constructs in C code however, for example: https://github.com/Hirrolot/datatype99

Nice reference but with some strange bits:

> Algebraic data types are usually represented using a heap. Because of their non-uniformity, algebraic data types are more difficult to scan.

Using a heap??? We can represent ADTs using stack as well, that's what we usually do in C and Rust.

Shameless plug: https://github.com/Hirrolot/datatype99 (a library of mine that generates type-safe ADTs for pure C99).

I agree; I would especially not recommend abusing macros throughout an application codebase too much. Conceptually, Metalang99 is more of a (sub)language than a library, which also adds some entry barrier. Ideally, I see the application of Metalang99 being used "behind the scenes", e.g., encapsulated in separate code files/libraries such as Datatype99 and Interface99. This is what I (mostly) do in SmolRTSP.

I've done something similar with Datatype99 and Interface99. They are like a macro eDSL that compiles to C. The first one features algebraic data types, the second one features interfaces.

If you need a bit more high-level constructions, you can use the Datatype99 and Interface99 libraries. The former provides polymorphism over data, the latter -- over behaviour (I am the creator of these libraries).

OP, you might find datatype99 and its sibling projects interesting, though they mostly leverage the C preprocessor without going all the way towards defining a new language.

You can use Datatype99 to represent your AST tagged union conveniently.

Compared to plain C, you have ADTs which help from day to day programming. You can bring them to C (https://github.com/Hirrolot/datatype99) but I don't know if the Linux guys would allow it.