Re: mark_stack () vs GCPROn

[Stefan Monnier]

>> Emacs has a `mark_stack' function in alloc.c, which looks for (potential)
>> Lisp_Objects located on the current C stack.  Does it mean that GCPROn
>> mechanism is not necessary for local Lisp_Object variables now ?
> If stack marking is supported, then yes in general; but GCPROs are also
> used for debugging. This is controlled by GC_MARK_STACK in lisp.h.

Actually, other than to debug the mark_stack, I can't see how the GCPROs
can be used to debug anything.

But we still have the GCPROs because we're not sure if all the platforms
on which Emacs is used can use mark_stack.  So we keep the macros around
and define them as no-ops for the cases where we know mark_stack can be used.

> In short, GCPRO is faster because you don't need to check whether the word
> in memory is a Lisp_Object.

More specifically, with GCPRO the collector is faster since it doesn't
need to check the whole stack.

But with GCPRO the mutator can is slowed down since it needs to maintain
the gcprolist so it's ready if/when the GC needs it.

But without GCPRO the allocation is slowed down because it has to keep
track of all allocated areas such that mark_stack can reliably detect
whether a given value points to a valid object or not.

Until recently, the end result was that the GCPRO case was slightly
faster overall, but Dmitry recently installed a patch which reduces the
allocation overhead of the no-GCPRO case, making the non-GCPRO case just
as fast as the GCPRO case overall.

> But stack marking is much more useful because you don't need to check
> whether C code calls Feval (and so potentially Fgarbage_collect) and
> so you don't worry about protecting local Lisp_Objects.

Yes, it's a lot more convenient and a lot less error prone (nowadays,
since all common platforms use the no-GCPRO option, any platform that
uses GCPRO is likely to be broken because it's easy to handle it
incorrectly somewhere).

> BTW, the more important distinction is that the GCPRO-assisted collection
> is exact:

Actually, while it can be exact, Emacs's GCPRO annotations have never
been good enough for that.  At least depending on what you mean by
"exact".

E.g., the GCPROs should be "exact enough" to make sure we find and mark
all the objects that are live.  But they do not try to be exact to the
extent that we can find all the pointers to live objects.  So, if we
were to try and use a moving collector, we'd quickly find that some
objects can be found from the gcprolist but can't be moved because there
are other pointers to these objects which are on the stack but are not
in gcprolist.

In the other direction, the GCPROs we have will hold on to some objects
which are dead, for the simple reason that the UNGCPRO happens to be
placed a bit late in the code.


        Stefan