Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

[Pip Cet]

> I'm not sure what we should do with it, tho:

I think the simple awareness that doing the switch at some point in
the future is feasible is quite enough to satisfy me. Part of what
triggered this was what I perceived as a "switching GCs is impossible,
so let's not worry about it at all" attitude.

My main reason for writing a converter in the first place is that as
the Emacs code base is relatively stable, at least as far as using
regular and well-structured C code goes, there's no rush to do
anything. I'll probably just continue to lurk on the list until I hear
someone say something that makes me think they'd benefit from running
(part of) the converter, then pounce :-), and I hope my converter will
still work then.

> I don't think building Emacs by preprocessing all files through a C->C++ 
> converter is going to be a very popular proposition (e.g. will make debugging 
> the "C" code even more fun).

I agree completely. The current converter uses Perl and Marpa, which
are Free Software but not GNU, so it's definitely not an option.

But let's not make it any harder to eventually move to a moving GC. In
particular, let's require save values to know where their Lisp_Objects
are! I've ignored that issue for now, but "potential Lisp_Object" is a
bad thing to have. (For the same reason, I would like to submit a
patch to change SAFE_ALLOCA to SAFE_ALLOCA_LISP where the latter is
appropriate). I think the current compromise whereby stack values are
conservatively marked and heap values are precisely Lisp Objects or
not is good.

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

Lisp_Object f(Lisp_Object arg)
{
    Lisp_Object val = XCDR (arg);
    return val;
}

would become

Lisp_Return_Value f(Lisp_Handle arg)
{
     Lisp_Value val = XCDR (arg);
     return val;
}

I don't think that's horrible, though better names could surely be
found, but others might disagree.

[1] I don't think there's a legal issue with merely using Perl and
Marpa to run a converter that I'd gladly transfer copyright of to the
FSF. If there is, please let me know!