From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: mark_stack () vs GCPROn Date: Thu, 06 Dec 2012 09:07:14 -0500 Message-ID: References: <1354784459583-271770.post@n5.nabble.com> <50C06FDB.5020203@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1354802851 15220 80.91.229.3 (6 Dec 2012 14:07:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2012 14:07:31 +0000 (UTC) Cc: Dmitry Antipov , Emacs-devel@gnu.org To: Sergey Mozgovoy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 06 15:07:44 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tgc73-0006Ay-Th for ged-emacs-devel@m.gmane.org; Thu, 06 Dec 2012 15:07:42 +0100 Original-Received: from localhost ([::1]:46650 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tgc6r-0006rJ-RT for ged-emacs-devel@m.gmane.org; Thu, 06 Dec 2012 09:07:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tgc6i-0006oy-RQ for Emacs-devel@gnu.org; Thu, 06 Dec 2012 09:07:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tgc6e-0004hY-3y for Emacs-devel@gnu.org; Thu, 06 Dec 2012 09:07:20 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:13970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tgc6e-0004hP-07 for Emacs-devel@gnu.org; Thu, 06 Dec 2012 09:07:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09soXOY/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLDiYSFBgNJIgcBboJkEQDiEKVd4R6gViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="209209041" Original-Received: from 108-161-115-152.dsl.teksavvy.com (HELO pastel.home) ([108.161.115.152]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 06 Dec 2012 09:07:14 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 619BD58F5C; Thu, 6 Dec 2012 09:07:14 -0500 (EST) In-Reply-To: <50C06FDB.5020203@yandex.ru> (Dmitry Antipov's message of "Thu, 06 Dec 2012 14:13:47 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155319 Archived-At: >> 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