From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Finding objects on C stack - alternate GCPRO Date: Thu, 17 Nov 2011 18:50:33 +0200 Message-ID: <83ipmid76u.fsf@gnu.org> References: <4EC38B72.1000101@yandex.ru> <87ehx6q5fg.fsf@escher.home> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1321548799 18420 80.91.229.12 (17 Nov 2011 16:53:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Nov 2011 16:53:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 17 17:53:12 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RR5D5-0006X5-Ua for ged-emacs-devel@m.gmane.org; Thu, 17 Nov 2011 17:53:12 +0100 Original-Received: from localhost ([::1]:43696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RR5D5-00038I-6r for ged-emacs-devel@m.gmane.org; Thu, 17 Nov 2011 11:53:11 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RR5D2-00037z-6X for emacs-devel@gnu.org; Thu, 17 Nov 2011 11:53:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RR5Cx-0007mz-Bj for emacs-devel@gnu.org; Thu, 17 Nov 2011 11:53:08 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:52533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RR5Cx-0007mn-3l for emacs-devel@gnu.org; Thu, 17 Nov 2011 11:53:03 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LUT00800D4ZK600@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 17 Nov 2011 18:52:25 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.237.133]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUT006MMDJBLIP0@a-mtaout20.012.net.il>; Thu, 17 Nov 2011 18:52:24 +0200 (IST) In-reply-to: <87ehx6q5fg.fsf@escher.home> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:146080 Archived-At: > From: Stephen Berman > Date: Thu, 17 Nov 2011 13:50:11 +0100 > > It suffices to ensure that at least one pointer to each object is > GC-protected; that way, the object cannot be recycled, so all pointers > to it remain valid. Thus, a particular local variable can do without > protection if it is certain that the object it points to will be > preserved by some other pointer (such as another local variable which > has a `GCPRO')(1). Otherwise, the local variable needs a `GCPRO'. > > If this is only needed on platforms that don't support gcc, shouldn't > the manual say that, or should GCPRO be mentioned at all? As long as Emacs supports platforms that don't use conservative stack marking, we cannot drop GCPROs from the sources, and we cannot stop requesting that new code uses GCPROs where they are needed on those few platforms. Btw, it's not GCC that allows to make GCPRO a no-op, it's the fact that the platform supports stack marking. I only mentioned GCC because the proposed alternative method does require GCC. > Perhaps I'm completely missing the point, since the only thing I > know about GCPRO is what's in the manual; if so, could someone > elaborate on the role of GCPRO, or if that's inappropriate here, > point me to relevant places (preferable comments) in the Emacs > sources or relevant external discussion? Thanks. GCPRO is needed when the C sources have pointers extracted from Lisp objects and want to preserve them across calls to `eval'. E.g., if you hold the pointer to the data of a Lisp_String in a C variable, and then call a function that can directly or indirectly call `eval'. In such cases, you want to tell GC that the Lisp object cannot be GC'ed.