Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

[Stefan Monnier]

> We could, at some point in the future that's definitely not now, have
> a flag day and run the preprocessor once[1] to disambiguate what are
> currently Lisp_Objects by their uses, all typedef'd to Lisp_Object.

IIUC by that you mean to somehow instrument all Lisp_Objects that are on
the stack (and are currently traced via the conservative stack scanner),
so that we can use a precise collector.

This will only be acceptable if after the switch, invalid code
(e.g. Lisp_Objects on the stack that aren't properly instrumented)
is automatically detected.  After all, we used to have some of that info
(i.e. we used to do precise stack scanning by manually
registering/deregistering Lisp_Objects on the stack.  It wasn't precise
enough for a moving GC, tho), but it was riddled with bugs because it
was only maintained by hand.

> Then switching garbage collectors becomes a matter of providing the
> right header file rather than having to go through all the source
> code, manually or with a converter. Again, there's no rush and no need
> to do everything at once.

No doubt, the GC can be changed.  There's been some attempts at using
the Boehm GC to replace Emacs's current GC, for example.  It never went
much further than an initial proof of concept, but I think it's pretty
clear that it can be done.  It's less clear if it can bring very many
benefits, OTOH (clearly a generational or a concurrent GC would be
desirable in some corner cases, but nowadays the GC is rarely a source
of complaints).

Also I think a non-moving GC will be a lot easier to accommodate.
I'm not sure how your code deals with cases where we take a Lisp_Object
and extract a C pointer from it which we keep long enough to survive
a GC.  Does your GC also trace through char* pointers into buffer text?


        Stefan