Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

The check doesn't have to be done for every build, but it needs to be
static (i.e. performed during something like compile-time, not
run-time).

> You mean GCPRO?

Yes.

> I'm not sure what you mean by "not precise enough";

I'm referring to the problem you saw:

    ... but was defeated because some places didn't GCPRO variables that
    they knew to be protected by upstream callers...

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

Interesting.  I wonder what part of your use patterns would cause that.
Do you remember of particular situations where this happens, or is it
just kind of all the time?

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

A moving GC is not necessarily better.  It's a popular choice in
languages with high allocation rates, because allocation is extremely
efficient (just move the allocation pointer forward) and because
a stop&copy of the youngest generation can usually recover a lot of
garbage with fairly little effort (because often there are much fewer
live objects in the young region than dead ones, so copying the live
objects is cheaper than (mark&)sweeping the dead ones).

But it's not like it doesn't have downsides.


        Stefan