I am seeking an efficient free software multi-thread compatible garbage collector (with a GPLv3 compatible license, running primarily on Gnu/Linux). I want e.g. to have 4 to 8 threads running in parallel -e.g. some sort of tiny Lisp-, and allocating simultaneously. Allocation rate is expected to be rather high -with lots of values being temporary (but mutation rate should be lower).

Boehm's conservative GC is widely used, but is a bit slow (e.g. slower than the GC inside Ocaml).

Gnu Epsilon GC is also a possibility....

And Rollendurchmesserzeitsammler is nearly Boehm compatible but claims to be faster (or at least more real-time friendly).

smieciuch GC is a precise GC, but I don't know if it multi-thread compatible (and it fails to compile with g++-4.8 on my Debian/Sid/x86-64).

SGCL is Windows specific.

MeixnerGC is LGPLv3 & could be compiled for multithread applications, but don't compile on 64 bits Linux because of casts from pointers to unsigned int (it should use intptr_t); this has been fixed in its 0.4 release of april 7th, 2014.

TinyGc is Boehm compatible, but smaller and slower.

Ravenbrook MPS is precise, generational, rumored to be very efficient. However the API is quite complex. Most allocations require a loop (which very often run only once).

I would prefer a precise generational copying GC .... Of course I can adapt to constraints provided by the GC (e.g. by providing relevant marking or forwarding routines or layout information, expliciting local pointers in C code and dealing with writing or reading barriers, etc...).

Any other hints?

To improve the question, I don't require an "easy-to-use" GC, but an efficient and multi-thread friendly one. The C (or C++) code will all be generated, so it is then reasonably easy to cope with requirements or conventions (e.g. write barriers, precise local roots on the call stack in some automatic variable, A-normal form, etc...) dictated by the GC (since it is just a matter of changing the C code generator to fit with these).

See also this answer on StackOverflow.

I did wrote several precise copying single threaded garbage collectors, e.g. qish & the MELT runtime; but multi-threaded GCs are harder.

PS it would be for an hypothetical MELT monitor in relation with GCC MELT (so GPLv3 compatibility is essential).

  • Most GCs work with some constraints on how program data can be layed out in memory. (E.g., what constitutes a pointer? How are they found?). You appear to want a GC with no such constraints (e.g., "conservative" collectors such as the Boehm collector). I think this is a missing requirement. [I think Boehm would object to being categorized as "inefficient" especially given the conservative requirement. What's your definition of "bit slow"?]
    – Ira Baxter
    Apr 4 '14 at 9:04
  • No, I can easily adapt to constraints provided by the GC. Apr 4 '14 at 10:01
  • Ok, outside of wanting a multi-thread garbage collector for C/C++, with GPL license, what other constrains you have and what exactly you don't want of it?
    – Braiam
    Apr 5 '14 at 22:35

Browse other questions tagged or ask your own question.