Re: New GC concept

[Daniel Mendler <mail@daniel-mendler.de>]

Interesting, thank you for working on this!

I had hoped that a new GC would surface at some point given the recent
improvements regarding native compilation. As you say this can bring
Emacs on par with modern managed language runtimes. Can you elaborate a
bit more of some of your concepts?

> * fully copying and compacting

How do you ensure that compaction works together with the conservative
stack scanning? You pin memory blocks, which are potentially referenced
by the stack?

> * generational

Do you rely on the OS memory protection as a write barrier to separate
the different generations, similar to how the bdwgc does that?

> * specialized GC spaces for conses, strings, arrays, and so on: no
stupid header word for cons cells bloating memory use by 50%!

Avoiding the headers is a good idea. You are using a first fit strategy
to find the next free space for a new object. How do you use the
headerless approach for objects of different sizes? Isn't it the case
that every block should then contain objects of only a single type and
of a single size? Probably most of the objects fall in a few size
classes, so it may be possible to do better than first fit?

Overall is your design similar to the approach of the bdwgc plus that a
memory/object layout tailored to the needs of Emacs and the compaction?
How well does such a GC hold up to a GC which is precise and does not
rely on the OS facilities for barriers? It appears such a precise GC is
impossible to retrofit on the existing Elisp runtime, so I assume your
approach is the right way to go.

Daniel Mendler