Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

[Pip Cet <pipcet@gmail.com>]

On Sat, Nov 25, 2017 at 4:15 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> 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.

Yes, that is, I think, what I'm doing.

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

Hmm. Is that for every build, or as a debugging option? Doing it for
every build is hard, doing it as a debug option should be possible:
after all, there'd be no more Lisp_Objects, just stack values, heap
values, and return values, which could use
__attribute__((constructor)) to check they are indeed on the heap,
stack, or that their __builtin_frame_address changes.

(I'm also treating pointers and arrays specially, but that's mere optimization.)

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

You mean GCPRO? I'm not sure what you mean by "not precise enough"; I
briefly tried using the GCPRO information to keep track of stack
Lisp_Objects, but was defeated because some places didn't GCPRO
variables that they knew to be protected by upstream callers, as well
as the bugs.

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

I guess I'm an exceptional user, then, because I complain about it a
lot. It's very much in embarrassing-pause territory here.

> Also I think a non-moving GC will be a lot easier to accommodate.

I suspect that I don't fully understand the benefits of a moving GC,
because memory fragmentation alone simply has never been a problem for
me.

I've compromised by, as I said, combining the disadvantages of both
approaches (though "disadvantages" can be read as "debugging
opportunities"): Lisp_Objects are JS::Values whose JS_GetPrivate
pointers are constant, even though the JS::Value isn't. So that's
essentially a non-moving GC with extra error checking (because even
Qnil can move (from one non-zero representation to another, too), and
has, which was a little confusing to debug).

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

Right now, it doesn't, because the C pointer is constant. It should be
easy enough to convert, say, buffers and real vectors, because they
have accessor methods/macros. Frames would be a lot harder (but then
there are few enough of those that we can just accept they don't
move).

> Does your GC also trace through char* pointers into buffer text?

No.