mark_stack () vs GCPROn

mark_stack () vs GCPROn

[Sergey Mozgovoy]

Hello,

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 ?  It is
quite clear that gcprolist is still necessary for static Lisp_Objects.
What are the relationships between these 2 approaches for marking objects ?
My impression is that mark_stack() was introduced after the GCPRO thing and
partially superseded it, though I feel that I may be overlooking something.

Best regards,
Sergey Mozgovoy.



--
View this message in context: http://emacs.1067599.n5.nabble.com/mark-stack-vs-GCPROn-tp271770.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: mark_stack () vs GCPROn

[Dmitry Antipov]

On 12/06/2012 01:00 PM, Sergey Mozgovoy wrote:

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

> It is quite clear that gcprolist is still necessary for static Lisp_Objects.

IIUC you mix staticpro and GCPRO.

> What are the relationships between these 2 approaches for marking objects ?

In short, GCPRO is faster because you don't need to check whether the word
in memory is a Lisp_Object. 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.

BTW, the more important distinction is that the GCPRO-assisted collection
is exact: you always know where the Lisp_Objects are, and mark them. Stack
marking is conservative, e.g. treats everything which looks like
the valid Lisp_Object as Lisp_Object. For example, if you have Lisp_Object
at 0x12345678 and this object is not accessible from other objects, but
there is an integer value 0x12345678 somewhere on C stack, the object will
be marked. This way the collector doesn't reclaim some dead objects, which
is impossible if GCPRO is used.

Dmitry

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