* mark_stack () vs GCPROn @ 2012-12-06 9:00 Sergey Mozgovoy 2012-12-06 10:13 ` Dmitry Antipov 0 siblings, 1 reply; 3+ messages in thread From: Sergey Mozgovoy @ 2012-12-06 9:00 UTC (permalink / raw) To: Emacs-devel 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: mark_stack () vs GCPROn 2012-12-06 9:00 mark_stack () vs GCPROn Sergey Mozgovoy @ 2012-12-06 10:13 ` Dmitry Antipov 2012-12-06 14:07 ` Stefan Monnier 0 siblings, 1 reply; 3+ messages in thread From: Dmitry Antipov @ 2012-12-06 10:13 UTC (permalink / raw) To: Sergey Mozgovoy; +Cc: Emacs-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: mark_stack () vs GCPROn 2012-12-06 10:13 ` Dmitry Antipov @ 2012-12-06 14:07 ` Stefan Monnier 0 siblings, 0 replies; 3+ messages in thread From: Stefan Monnier @ 2012-12-06 14:07 UTC (permalink / raw) To: Sergey Mozgovoy; +Cc: Dmitry Antipov, Emacs-devel >> 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-12-06 14:07 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-06 9:00 mark_stack () vs GCPROn Sergey Mozgovoy 2012-12-06 10:13 ` Dmitry Antipov 2012-12-06 14:07 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.